Тема 10

Преобразуване на IP адреси и физически адреси - ARP, DHCP.

Table of Contents
ip-mac.png
Примерната конфигурация съдържа два ЕТЕРНЕТ сегмента и един FDDI сегмент , който е оптически сегмент. Тези два сегмента излизат на FDDI със два рутера R1 и R3. От гледна точка на IP тази конфигурация представлява следното – има три мрежи от клас С със стандартна маска 24. ЕТЕРНЕТ сегментите са свързани със опорна мрежа. Така се прави една кампусна мрежа а в рамките на сегментите има ЕТЕРНЕТ мрежи.
Първият компютър има да изпрати един IP Datagram към втория адрес. Той я формира и в нея ще има source address и destination address. Той трябва да я сложи в ЕТЕРНЕТ кадър така че трябва да разполага със физическия адрес на получателя адрес Е1 но не знае (2) на кой адрес отговаря – знае само неговото IP. И тоест не може да адресира кадъра тъй като са в много точков канал. Спрямо него абонат едно може да прецени че са във една мрежа и следователно най-вероятно са в един и същи ЕТЕРНЕТ сегмент. Това че МАС адреса няма нищо общо със IP адреса определено не означава проблем за комуникация в рамките на един ЕТЕРНЕТ сегмент. Следователно на ниво между второ и трето към всеки компютър, който се свързва към ЕТЕРНЕТ мрежа и който има TCP-IP стек се въвежда ARP - address resolution protocol. Целта на този протокол е да дава отговор на кой IP адрес кой МАС адрес отговаря .
Как работи този протокол? Той познава особеностите на второ и на трето ниво. Към всеки компютър свързан в ЕТЕРНЕТ мрежа в операционната памет се формира в стековете за протоколи ARP cache, в който се пазят съответствията на IP и ЕТЕРНЕТ адреси. Търсения IP адрес се търси дали вече не е постъпил в кеш таблицата на абонат 1. В началото тя е празна. След това се пита в ЕТЕРНЕТ сегмента дали някой си разпознава IP адреса. Това става със кадър ARP request. В полето тип на кадъра има специален номер,който указва тип ARP RQ. Той формира кадър който съдържа broadcast MAC адрес съставен от 48 единици, като destination address. Тип на кадъра ще е ARP RQ. В полето за данни ще има 192.31.65.5 (съответния IP адрес, който се търси).

111……11111111 Е1 АRP RQ IP E2 IP E1 FoS

Всички абонати в мрежата получават този кадър и проверяват дали адресът е техният. Ако не е всички си го записват в кеша. Това е процес на самообучения. Ако някой си познае адреса ще върне ARP response във два варианта. Единия е като destination address да сложи само адреса на Е1 и по този начин другите няма да получат този кадър. Другия вариант е отговора да се пусне broadcast. Така всички ще си запищат второто съответствие в кеш таблиците, тоест в този случай се попълва кеш таблицата и на всички останали. Това става ако двата абоната са във една мрежа.
Ako destination IP address е от другата страна – например адреса на Е6, как ще процедира Е1. Рутерите работят на трето ниво. Те декодират пакета и го подготвят отново. Те не пускат broadcast на канално ниво. Имат по два интерфейса – по един за FDDI и за ЕТЕРНЕТ мрежата. Ако се направи IRP request със този адрес, то рутера има възможност да знае с кои други рутери е свързан и че е default рутер на сегмента. И в двата случая ще отговори със Е3, тоест ще даде своя МАС адрес като отговорник за този IP адрес. IP datagram – а ще дойде в рутера като кадър. Там той ще се декадрира и ще пусне ARP RQ във FDDI мрежата със 192.31.63.0 Това питане ще обиколи и и тогава другия рутер ще види че той е от другата страна на тази мрежа и ще върне като адрес F3 – адреса на FDDI интерфейса си . Ако няма съответствие на адреса във ARP кеша то той ще подготви нов кадър в който ще пита в тази мрежа дали има такъв адрес. При този случай абонат номер 6 ще му върне нов ARP response със физическия си адрес и той ще го запише във кеша. Така този адрес ще е запомнен и вече ще изпраща datagram-ите със физически адрес Е6. Така се прехвърля datagram във една кампусна мрежа.
Има и reverseARP или rarp, в който с broadcast сигнал се пита за определен МАС адрес дали някой знае какъв му е IP адреса. Може да се поддържа или ако някой от устройствата го има в кеша, или ако се използва специален RARP сървър. Това в днешно време не се използва, за целта се използват DHCP сървъри, които се използват за такива станции които не си знаят IP адреса.

UDP протокол
(…схема….)
(…огрооомна схема….)

При TCP-IP са възможни само два подхода на четвърто ниво. – UDP и TCP

Bits 0 - 15 16 - 31
0 Source Port Destination Port
32 Length Checksum
64 Data Data

Формат на UDP протокола
UDP означава user datagram protocol. Той е протокол на транспортния слой ориентиран към минимални съобщения и осигурява много прост интерфейс между третия слой (интернет слой), и четвъртия (приложен) слой. UDP не осигурява никакви гаранции на протокола от горния слой за достигане на съобщението, и изпращашия UDP не получава никакво състояние на UDP съобщенията когато вече са изпратени. (Поради тази причина понякога наричат UDP – unreliable datagram protocol). UDP добавя само мултиплексиране и контролна сума на хеадъра. Ако има някакъв вид надеждност на информацията се изисква, то тя трябва да е имплементирана на по горните слоеве.

The UDP header consists of only 4 fields. The use of two of those is optional (pink background in table).
Source port
This field identifies the sending port when meaningful and should be assumed to be the port to reply to if needed. If not used, then it should be zero.
Destination port
This field identifies the destination port and is required.
Length
A 16-bit field that specifies the length in bytes of the entire datagram: header and data. The minimum length is 8 bytes since that's the length of the header. The field size sets a theoretical limit of 65,535 bytes (8 byte header + 65527 bytes of data) for a UDP datagram. The length includes the UDP header, so the minimum size for a UDP datagram is 8 (8 byte header with no data). The practical limit for the data length which is imposed by the underlying IPv4 protocol is 65,507 bytes.
Checksum
The 16-bit checksum field is used for error-checking of the header and data.
UDP хедъра се състои само от 4 полета. Използването на две от тях е опционално.
- порт на източника – source port – това поле идентифицира изпращащия порт и когато е от значение трябва да означава порта, на който трябва да се отговори ако е необходимо. Ако не се използва трябва да е 0.
- порт на получателя – то идентифицира получателя и е задължително
- дължина – 16 битово поле което специфицира дължината във байтове на целия datagram – header и данни. Рамера на това поле поставя теоритично ограничение от 65,535 bytes (8 byte header + 65527 bytes данни) за UDP datagram. Дължината включва и UDP header-а затова минималния размер за UDP datagram е 8 байта за datagram без данни. Практически ограничението за дължината на данните поставено от стоящия отдолу IPv4 протокол е 65,507 байта.
Номерата на портовете в диапазона от 0 до 1024 са well known – те са резервирани и с определено предназначение. Тоест като се сложи номер на destination port се знае предназначението му. Във IP обмена участват освен IP адреси и номера на пoртове. Номера на порт се задава като десетично число от 0 до 216 -1.

DHCP.png
Протокола DHCP- dynamic host configuration protocol се изпълнява за разпределяне на IP адреси при компютри в които няма статичен такъв. Единия начин за едно устройство да се определи IP адрес е той ръчно да се въведе, заедно със subnet mask и адрес на рутера. Ако не е хубаво този компютър да е със статично IP , то тогава се изпълнява DHCP протокола. За да работи това трябва да има DHCP сървър в конфигурация с него. Има пространство от динамични адреси, които той може да им раздава в определен срок. На този сървър трябва да се каже диапазона, който се раздава за статични IP адреси. Трябва да има DHCP агент, който знае къде е DHCP сървъра. Може да има повече от един DHCP сървър в конфигурацията.
В началото клиента нищо не знае. Първата му работа е да открие дали има DHCP сървър и да получи предложения за разни адреси. Процедурата по получаване на един адрес е четирифазна. Новия клиент на сървъра означен със (?) прави в началото UDP datagram, в която негов source address е 0.0.0.0 защото е абсолютно бос. Портът, по който се пита за DHCP е порт 68. Той се нарича bootstrap client. Destination address е broadcast адрес със порт 67 – това е порта на DHCP сървъра. Типът се нарича DHCP discover. Питащия слага номер на транзакцията, в случая клиента и агента са в рамките на един сегмент, тоест тази UDP datagram е затворорена в 1 broadcast кадър. Този broadcast попада в агента, който е маршрутизатор и този агент го пуска в другия сегмент. Този агент, освен че е маршрутизатор знае и адреса на DHCPсървъра. За discovery този сървър получава кадрите и си записва номера на транзакцията и пуска своята оферта. Затова има предварително разузнаване и офериране. В тази оферта се съдържа IP адрес, който отговаря на този номер на транзакция. Устройство 3 трябва да получи отговора и да разпознае че това е неговия адрез. Може клиента да получи няколко оферти. Тези адреси ще бъдат коректни, но могат да са в различни диапазони. За два сървъра адресите не се пресичат. На новия клиент му се дава избор от адреси, които са специалиално предназначени за тази цел. Има и друга възможност DHCP да помни какви адреси от кого са взимани и да предпочете да дава същия адрес, особено ако включването и изключването стават често. Клиента чака да събере оферти. Има и time out. Той взима решение към коя оферта да се насочи. Насочва се към офертата на сървъра, който е най близо. След като е оферирал той прави отново request, в който слага адреса, който иска. Пак го подава като broadcast и вкарва в него разни чисълца. Това се прави, защото може да е изтекла офертата. Не винаги DHCP пази предложените адреси. Сървъра му предоставя този адрес като му дава DHCP acknowledge със получения адрес и клиента си конфигурира настройките с него. Тези 4 фази се правят, защото иначе могат да се създадат различни конфликтни ситуации.
Важно за интернет провайдърите е да разполагат с динамично пространство за да не си конфигурират сами клиентите настройките. DHCP сървъра си води сметка какъв адрес е дал, няма да се получи IP conflict по този начин.

NAT

IP адреса може да се преобразува от една мрежа в друга – това е така наречения NAT – network address translation. Тази транслация се прави от специялен маршрутизатор на изхода на една локална мрежа. Той освен маршрутизация прави и транслация на адресите. От практическа гледна точка има две предимства – намалява се броя на използваните световни IP адреси. Под един адрес могат да се скрият много абонати. СЪс това скриване се прави и защита от неоторизиран достъп.

(..insert picture here…)

На картинката се разглежда една локална мрежа като сегмент, в който са раздадени тези адреси, които не се разглеждат от рутерите. Тъй като това не е реален интернет адрес, те могат да се раздават свободно в затворената мрежа. Абонат 1 генерира IP datagram с негов source address. Когато един абонат изпраща заявка , той си генерира случаен номер на порт, който е по-голям от 1024, тъй като не трябва да е запазен. Това е номера на порта, от който започва неговото искане. Destination address е адрес на web server. Номерата на портовете означават номер на този процес – 80 е запазен порт за http server. Дейтаграмата постъпва на default рутера през протокола като кадър. Този рутер знае IP адресите в рамките на тази мрежа. NAT като получи тази дейтаграма я хваща и за да я излъчи си слага своя IP адрес като source address. Неговия адрес е реален интернет адрес даден от интернет администраторите. За номер на порта си измисля друг номер, като го запазва. И тази дейтаграма я пуска във мрежата и попада в сървъра. Междувременнорутера си пддържа MAC таблица със записи кой адрес и кой сокет на кой адрес и със кой порт отиват. Важно е, че променя номера на портовете, тоест бърка във дейтаграмата, която е структура от четвърто ниво. Отговора към абонатите става само по същия номер на порт който е подаден, всяка дейтаграма трябва да има отделен номер на порт и това ще е друг запис в таблицата. Далечния сървър връща отговор и слага адреса на маршрутизатора и номера на порта, получен във заявката. След получаване на дейтаграмата търси по номера на порта в таблицата. Тази таблица е на ниво приложение и е вътрешна за рутера. Като влезе дейтаграмата, рутера ще намери транслация и ще смени IP адреса и порта на получателя. На този порт е била закачена заявката към http сървър. Задачата на това транслиране е само да сменя IP адреси, и за да постийне това сменя номерата на портовете.
Произволно количество адреси се изобразяват през един реален IP адрес. Това се прави деста често. Принудителния недостатък е че се нарушава основната концепция на енкапсулация.В такава мрежа не може да се сложи сървър. За да се направи това трябва да има демилитализирана зона от реални адреси.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License