http___fmi.wikidot.com_km10_1.xml
https___wizkidblogs.wordpress.com_2016_08_25_exploring-dhcp-requests_.xml
1.1 2.1 2.2 2.3 2.4 2.5 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 5.1 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 8.1 8.2 8.3 9.1 10.1 11.1 12.1 12.2 13.1 14.1 14.2 14.3 14.4 14.5 14.6 15.1 15.2 16.1 17.1 17.2 18.1 19.1 20.1 21.1 21.2 21.3 21.4 21.5 22.1 23.1 24.1 24.2 25.1 25.2 26.1 27.1 27.2 27.3 27.4 28.1 28.2 28.3 28.4 29.1 29.2 29.3 29.4 29.5 29.6 29.7 29.8 30.1 30.2 30.3 30.4 30.5 30.6 30.7 30.8 30.9 30.10 30.11 30.12 30.13 30.14 30.15 30.16 30.17 30.18 30.19 30.20 30.21 30.22 30.23 30.24 30.25 30.26 30.27 30.28 30.29 30.30 31.1 31.2 32.1 33.1 33.2 33.3 33.4 33.5 33.6 34.1 35.1 35.2 35.3 35.4 35.5 35.6 35.7 35.8 35.9 35.10 35.11 35.12 35.13 35.14 35.15 35.16 35.17 35.18 35.19 35.20 35.21 35.22 36.1 36.2 36.3 36.4
Преобразуване на IP адреси и физически адреси - ARP, DHCP. Примерната конфигурация съдържа два ЕТЕРНЕТ сегмента и един 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 Формат на 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- 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 адрес. Това се прави деста често. Принудителния недостатък е че се нарушава основната концепция на енкапсулация.В такава мрежа не може да се сложи сървър. За да се направи това трябва да има демилитализирана зона от реални адреси.
1.1 2.1 3.1 4.1 5.1 6.1 7.1 8.1 9.1 10.1 11.1 12.1 13.1 14.1 15.1 16.1 16.2 16.3 16.4 17.1 18.1 19.1 20.1 20.2 21.1 21.2 22.1 22.2 23.1 24.1 24.2 25.1 26.1 26.2 27.1 28.1 28.2 29.1 29.2 29.3 30.1 31.1 32.1 32.2 32.3 32.4 33.1 34.1 34.2 34.3 35.1 36.1 36.2 37.1 38.1 39.1 40.1 41.1 41.2 42.1 42.2 43.1 44.1 44.2 45.1 46.1 46.2 46.3 47.1 48.1 49.1 50.1 51.1 52.1 53.1 54.1 54.2 55.1 56.1 57.1 58.1 58.2 58.3 59.1 60.1 61.1
In this article I would like to explore DHCP requests so that we can understand what happens when a device sends a request to a DHCP server. Lets start by listing some important information about DHCP….. - DHCP is the abbreviation for Dynamic Host Configuration Protocol - DHCP uses UDP 67 & 68 – 67 – In a client-server environment port 67 is the BOOTP for the DHCP server and 68 is the BOOTP for the client - The purpose of DHCP is to assign IP addresses automatically to the device that has requested an IP address How does the client interact with the DHCP server? In short… - The client sends a DISCOVER frame asking for an IP address - The DHCP server responds with an OFFER which contains an IP address and additional information - The client sends a REQUEST to use the IP address contained in the OFFER - The DHCP server ACKNOWLEDGES the request to use the IP address The above process is what happens on the surface however there is a lot more going on if we take a look at the frames using Wireshark. Behind the scenes of a DHCP request… Below is the topology we are going to work from to explain the DHCP process in depth. Image .1 The client on the left doesn’t have an IP address yet and would like to request one from the DHCP server located at 10.0.4.4. The switches are configured with ip helper-addresses to relay DHCP information. ESW1 has a VLAN 10 static IP address of 10.0.0.2. The ip helper-address and ESW1 IP address are only relevant so I can explain the Wireshark capture pictured below. Image.2 We have a lot of detail to cover so I will break each frame down using the numbers (No.) in the above image and then within those numbers we will examine the information further. Frame Number 383. This is the first frame sent by the client when requesting an IP address automatically. On the surface of image .2 we can see that the source IP address is 0.0.0.0, the destination IP address is 255.255.255.255, the protocol is DHCP and in the info we can see that it is a DHCP Discover message. The reason the client has a source IP address of 0.0.0.0 is because it doesn’t currently have a layer 3 address. The client doesn’t know the IP address of the DHCP server so it sends the frame with a destination IP address of 255.255.255.255 which is a broadcast address. If we look at image .3 below, we start by examining the Layer 2 information. As with the client not knowing the destination IP address, it also doesn’t know the destination MAC address so it too sets the destination MAC address to a broadcast of ff:ff:ff:ff:ff:ff. Image .3 If we now take a look at the Layer 3 information in Image .4 we can see that the source IP address is set to 0.0.0.0 and this is because the client doesn’t currently have an I P address. The destination address is set to 255.255.255.255 and this is because the client doesn’t know the destination address of the DHCP server so it sends it to the broadcast L3 address. Image .4 If we take a look at the protocol and port information in Image.5 we can see the source port that the DHCP Request has originated, Port 68. The destination port is that of a DHCP server and the protocol is UDP which is connection-less. Image .5 The last field in the Discover frame is the Bootstrap protocol. The BOOTP protocol is defined in RFC 951 as a protocol that assigns IP addresses and other information to networking devices. If we look at the BOOTP fields in Image .6 we can see much of the information we have already identified along with option fields. In option (12) we can see that the client has been identified as SALES1. Much of this information will change in the frames we examine later on. Image .6 This concludes Frame number 383 which was the DHCP Discover frame, we will now move onto the DHCP Offer packet number 385. For Packet number 385 I have missed out the Layer 1 and Layer 2 information as there isn’t anything particular interesting to explore. In Image 7. we start with the Layer 3 information and we can see the original source IP address of the ESW1 switch. If we look at the Destination IP address, you will see 10.0.0.51, this IP address is the one being offered to the client by the DHCP server. Image .7 Moving onto the Layer 4 information in Image .8 we can see some UDP information that is worth explaining. As the DHCP Offer is flowing back to the client PC from the server we can see that the Source port is 67 and the Destination port is 68. All we need to know about these two port numbers is that 67 is the bootstrap protocol (BOOTP) from the server and 68 is the bootstrap protocol (BOOTP) for the client. Image .8 Image .9 shows some very interesting information about the DHCP offer packet. If we look at the ‘Client IP address’ field we can see that the client still doesn’t have an IP address until this packet reaches the client and requests to have the IP address of 10.0.0.51 shown in ‘Your (client) IP Address’ field. The ‘Relay agent IP address’ field shows the IP address for the ESW1 switch as this is acting as the DHCP relay device. Skipping over some of the details we can see the subnet mask of the host in ‘Option (1)’ , we also see further down some more options that include the renewal information, lease time and DHCP server identifier. This concludes the inspection of the DHCP Offer packet 383, we will now have a look at what happens when the client receives the offer and chooses to accept the IP address. Image .9 So the client has now received the DHCP Offer and would like to accept the IP address 10.0.0.51 that the server offered. To do this the client first needs to respond to the server via the DHCP Request packet shown in Image.10. If we look at the Layer 3 information we can see that the client still hasn’t been assigned the 10.0.0.51 IP Address, this is because it doesn’t happen until the server acknowledges the Request packet. So the request message is still sent in this case as a Broadcast message on the network with a destination IP address of 255.255.255.255. Image .10 Looking at the Layer 4 information in Image .11 we can see that the Source port is 68 and the Destination port is 67. As mentioned earlier in this post, these port numbers represent the BOOTP Client and BOOTP Server. Image .11 Now this is where the inspection gets slightly more interesting with the DHCP Request packet. In Image .12 we can see that although the field ‘Next server IP Address’ shows the IP address of 0.0.0.0, further down in the options we see that the ‘DHCP Server Identifier’ shows the server address of 10.0.4.4. In ‘Option 50’ we see the requested IP address information that the client would like and further down we see the hostname of the client machine. ‘Option 55’ displays some additional information that the client would like to request, in this case we can see that the client would like the following: - Subnet Mask - Router (I believe this is the gateway information) - DNS settings - Domain name All this information makes up the DHCP Request packet so now we will take a look at what happens when the server receives the request and what it does next. Image .12 So now that the server has received the DHCP Request we just talked about the server sends an Acknowledgement to the client as shown in Image .13. If we take a look at the Layer 3 information we can see that the server sends the Acknowledgment packet to ESW1 switch at 10.0.0.2 who will then forward onto the client. Image .13 The Layer 4 information in Image .14 shows that the source port and destination port is the same for the Acknowledgement packet and I believe this is because the server is just sending and ACK only. Image .14 If we look at the last section of the Acknowledgement packet we can see that the server has sent all the additional information the client requested in the last packet. Then the last image named Image .16 shows ESW1 forward the ACK packet onto the client. This then completes the DORA process and the assignment of the dynamic IP Address to the client is complete. Image .15 Image .16 I hope you have found this post useful, if you have any questions please drop us a comment.