<पी> इंटरनेट प्रोटोकॉल संस्करण 4 (आईपीवी4) इंटरनेट और अन्य पैकेट-स्विच्ड नेटवर्क में मानक-आधारित इंटरनेटवर्किंग विधियों के मुख्य प्रोटोकॉल में से एक है। IPv4 अभी भी सबसे व्यापक रूप से तैनात इंटरनेट प्रोटोकॉल है। Google के IPv6 आंकड़े बताते हैं कि 24 अप्रैल, 2025 को Google सेवाओं पर 44.29% ट्रैफ़िक IPv6 से अधिक है, जिसका अर्थ है कि 55.71% IPv4 से अधिक है। <पी> यह हैंडबुक आपको आईपी पतों को समझने से लेकर पैकेट हेडर और विखंडन की जांच करने तक आईपीवी4 के हर पहलू से अवगत कराएगी। आप सीखेंगे: - <पी> IP पते कैसे काम करते हैं और उनके विभिन्न प्रारूप
- <पी> निश्चित-लंबाई से सीआईडीआर तक नेटवर्क एड्रेसिंग योजनाएं
- <पी> विशेष IPv4 पते और उनके उपयोग
- <पी> IPv4 हेडर में प्रत्येक फ़ील्ड की संरचना और उद्देश्य
- <पी> IPv4 विभिन्न नेटवर्कों में पैकेट विखंडन को कैसे संभालता है
<पी> चाहे आप नेटवर्क इंजीनियर हों, सॉफ़्टवेयर डेवलपर हों, या आईटी पेशेवर हों, आधुनिक कंप्यूटर नेटवर्क के साथ काम करने के लिए IPv4 को समझना महत्वपूर्ण है। हम क्या कवर करेंगे:
- <पी> पृष्ठभूमि
- <पी> आईपी एड्रेस को समझना
- <पी> नेटवर्क आईडी और होस्ट आईडी
- <पी> नेटवर्क बनाम होस्ट भाग का निर्धारण कैसे करें
- <पी> निश्चित-लंबाई दृष्टिकोण
- <पी> यहां क्या नुकसान हैं? 🤔
- <पी> क्लासफुल एड्रेसिंग
- <पी> आईपी एड्रेस असाइनमेंट
- <पी> यहां क्या नुकसान हैं? 🤔
- <पी> सीआईडीआर:क्लासलेस इंटरडोमेन रूटिंग
- वास्तविक दुनिया का उदाहरण
- <पी> सबनेट मास्क
- <पी> अंतरिम सारांश - IPv4 पते
- <पी> अपने आप को परखें
- <पी> प्रीफ़िक्स नोटेशन और सबनेट मास्क के बीच कनवर्ट करना
- <पी> सबनेट मास्क के साथ पीछे की ओर काम करना
- <पी> गैर-बाइट-संरेखित उपसर्ग
- <पी> नेटवर्क सदस्यता का निर्धारण
- <पी> विशेष IPv4 पते
- <पी> "यह होस्ट" पता:0.0.0.0
- <पी> "यह नेटवर्क" पते
- <पी> प्रसारण पते
- <पी> लूपबैक पते:127.0.0.0/8
- <पी> विशेष IPv4 पतों का सारांश
- <पी> IPv4 हेडर
- <पी> हेडर संरचना
- <पी> IPv4 हेडर - अंतरिम सारांश
- <पी> IPv4 विखंडन
- <पी> विखंडन की आवश्यकता क्यों है
- <पी> आईपी में विखंडन कैसे काम करता है
- <पी> पहचान फ़ील्ड
- <पी> फ़्रैगमेंट ऑफ़सेट
- <पी> अधिक टुकड़े करें और झंडे को खंडित न करें
- <पी> विखंडन उदाहरण
- <पी> IPv4 विखंडन - सारांश
- <पी> सारांश - IPv4
- <पी> संबोधन और नेटवर्क संरचना
- <पी> IPv4 हेडर संरचना
- <पी> विखंडन
- <पी> अंतिम शब्द
- <पी> लेखक के बारे में
- <पी> अतिरिक्त सन्दर्भ
शुरू करने से पहले त्वरित नोट्स
- <पी> आप कंप्यूटर नेटवर्क के बारे में अधिक सामग्री मेरे YouTube चैनल:कंप्यूटर नेटवर्क प्लेलिस्ट पर पा सकते हैं
- <पी> मैं कंप्यूटर नेटवर्क के बारे में एक किताब पर काम कर रहा हूँ! क्या आप प्रारंभिक संस्करण पढ़ने और प्रतिक्रिया देने में रुचि रखते हैं? मुझे एक ईमेल भेजें:gitting.things@gmail.com
पृष्ठभूमि
<पी> IP का अर्थ "इंटरनेट प्रोटोकॉल" है, इसलिए IPv4 इंटरनेट प्रोटोकॉल संस्करण 4 है। इसे सितंबर 1981 में प्रकाशित IETF द्वारा RFC 791 में वर्णित किया गया था, और पहली बार 1982 में SATNET (अटलांटिक पैकेट सैटेलाइट नेटवर्क) पर उत्पादन के लिए तैनात किया गया था, जो एक प्रारंभिक उपग्रह नेटवर्क था जिसने इंटरनेट का प्रारंभिक खंड बनाया था। <पी> IPv4 कनेक्शन रहित है और सर्वोत्तम प्रयास वाले डिलीवरी मॉडल में काम करता है। इसका मतलब यह है कि यह डिलीवरी, पैकेट के सही ऑर्डर या डेटा की वैधता की गारंटी नहीं देता है। इसे तेज़ और लचीला बनाने के लिए डिज़ाइन किया गया है। आईपी पते को समझना
<पी> आईपी पते पदानुक्रमित, तार्किक पते हैं जो आज अधिकांश इंटरनेट कनेक्शनों को शक्ति प्रदान करते हैं। प्रत्येक में 4 शामिल हैं बाइट्स, या 32 बिट्स वे आमतौर पर बिंदीदार दशमलव संकेतन में लिखे जाते हैं, उदाहरण के लिए: <पी> 
<पी> स्वयं का परीक्षण करें - क्या निम्नलिखित पता एक वैध आईपी पते का प्रतिनिधित्व करता है? <पी> 
<पी> नहीं, चूँकि बिंदु अलग-अलग बाइट्स को अलग करते हैं, प्रत्येक मान 0 के बीच होना चाहिए और 255 . चूंकि संख्या 200 है 255 से बड़ा है , इसे एक बाइट में प्रस्तुत नहीं किया जा सकता। <पी> 
नेटवर्क आईडी और होस्ट आईडी
<पी> IP पते के दो भाग होते हैं:एक नेटवर्क पहचानकर्ता (या नेटवर्क आईडी) जो नेटवर्क में सभी होस्ट और एक होस्ट पहचानकर्ता से संबंधित है (या होस्ट आईडी) जो इस नेटवर्क में विशिष्ट होस्ट की पहचान करता है। <पी> नेटवर्क पहचानकर्ता नेटवर्क में सभी होस्ट के लिए समान होगा, और इसे "उपसर्ग" भी कहा जाता है। उदाहरण के लिए, 201.22.3 के नेटवर्क पहचानकर्ता पर विचार करें . यह देखते हुए कि यह नेटवर्क उपसर्ग है, निम्नलिखित पते: 201.22.3.15
201.22.3.91
<पी> वे एक ही नेटवर्क का हिस्सा हैं, क्योंकि वे एक ही उपसर्ग साझा करते हैं। पहला पता होस्ट नंबर 15 का है इस नेटवर्क में, और दूसरा होस्ट नंबर 91 का है . <पी> इस पते में एक अलग उपसर्ग, या एक अलग नेटवर्क पहचानकर्ता है, और इस प्रकार यह एक अलग नेटवर्क से संबंधित है: 201.22.14.50
<पी> ऊपर दिए गए उदाहरणों में, एक नेटवर्क पहचानकर्ता है जिसमें 3 बाइट्स, या 24 बिट्स हैं, और एक होस्ट पहचानकर्ता है जिसमें 1 बाइट, या 8 बिट्स हैं। <पी> 
नेटवर्क बनाम होस्ट भाग का निर्धारण कैसे करें
<पी> एक प्रश्न उठता है:आप कैसे जानते हैं कि कौन से बिट नेटवर्क आईडी का हिस्सा हैं, और कौन से होस्ट आईडी का हिस्सा हैं? इस चुनौती से निपटने के लिए समय के साथ कई दृष्टिकोण विकसित हुए हैं। निश्चित-लंबाई दृष्टिकोण
<पी> आइए इस समाधान पर विचार करें:प्रत्येक आईपी पते के लिए, पहला, सबसे महत्वपूर्ण बाइट नेटवर्क आईडी का प्रतिनिधित्व करेगा, और शेष तीन, सबसे कम महत्वपूर्ण बाइट्स होस्ट आईडी का प्रतिनिधित्व करेंगे। इस तरह आईपी पते को पढ़ना वास्तव में आसान है। उदाहरण के लिए इस पते के लिए: 20.12.1.92
<पी> आप जानते हैं कि यह नेटवर्क 20 का वर्णन करता है , और होस्ट 12.1.92 उस नेटवर्क के अंदर. कोई भी आईपी पता जो 20 से शुरू नहीं होता है , जैसे 22.1.2.3 , एक अलग नेटवर्क में रहेगा, और कोई भी आईपी पता जो 20 से शुरू होता है , जैसे 20.1.2.3 , एक ही नेटवर्क के भीतर होगा। <पी> 
यहां क्या नुकसान हैं? 🤔
<पी> नेटवर्क आईडी का प्रतिनिधित्व करने के लिए केवल एक बाइट (8 बिट्स) के साथ, आपके पास केवल 2^8, या 256 है , विभिन्न नेटवर्क। बेशक, वास्तविक दुनिया की तुलना में कहीं अधिक नेटवर्क हैं। यहां तक कि इंटरनेट के शुरुआती दिनों में भी, विश्वविद्यालयों और बड़ी कंपनियों को अपने स्वयं के नेटवर्क पहचानकर्ताओं की आवश्यकता होती थी। <पी> सामान्य तौर पर, नेटवर्क आईडी के लिए एक निश्चित लंबाई और होस्ट आईडी के लिए एक निश्चित लंबाई का उपयोग करना पर्याप्त लचीला नहीं है। यदि आप तय करते हैं कि दो सबसे महत्वपूर्ण बाइट्स नेटवर्क आईडी का प्रतिनिधित्व करेंगे और दो सबसे कम महत्वपूर्ण बाइट्स होस्ट आईडी का प्रतिनिधित्व करेंगे, तो आप 2^16, या 65,536 तक प्रतिनिधित्व कर सकते हैं। नेटवर्क, जो भी पर्याप्त नहीं है। इसके अलावा, कुछ नेटवर्क, जैसे कि बड़ी कंपनियों को, 65,536 से अधिक की आवश्यकता हो सकती है होस्ट आईडी. क्लासफुल एड्रेसिंग
<पी> समाधान कुछ लचीलापन प्रदान करने में निहित है। "क्लासफुल एड्रेसिंग" नामक एक अन्य दृष्टिकोण पर विचार करें। इस दृष्टिकोण में, नेटवर्क आईडी के लिए समर्पित बिट्स की संख्या एक पते से दूसरे पते में बदल जाती है, और आप पते के पहले, सबसे महत्वपूर्ण बाइट को देखकर नेटवर्क आईडी बता सकते हैं। - <पी>
1 के बीच की संख्या से शुरू होने वाला कोई भी पता और 127 "क्लास ए" से संबंधित है, जिसका अर्थ है कि इसकी नेटवर्क आईडी में 1 बाइट है, होस्ट आईडी के लिए 3 बाइट छोड़ता है।
- <पी>
128 के बीच की संख्या से शुरू होने वाला कोई भी पता और 191 "क्लास बी" से संबंधित है, जिसका अर्थ है कि इसकी नेटवर्क आईडी 2 बाइट लंबी है, और इसकी होस्ट आईडी भी 2 बाइट लंबी है।
- <पी>
192 के बीच की संख्या से शुरू होने वाला कोई भी पता और 223 "क्लास सी" से संबंधित है, इसलिए इसमें नेटवर्क आईडी के 3 बाइट और होस्ट आईडी के 1 बाइट हैं।
<पी> आप इस दृष्टिकोण का पूरा प्रतिनिधित्व नीचे दी गई तालिका में देख सकते हैं: क्लासफर्स्ट बाइट रेंजनेटवर्क आईडी साइजहोस्ट आईडी साइज ए1 - 127 1 बाइट3 बाइट्सबी128 - 191 2 बाइट्स2 बाइट्सC192 - 223 3 बाइट्स1 बाइट्सडी224 - 239 (मल्टीकास्ट)ई240 - 255 (आरक्षित) <पी> 
<पी> उदाहरण के लिए, यह पता किस वर्ग से संबंधित है? (1) 130.12.204.5
<पी> चूँकि यह 130 से शुरू होता है , जो 128 के बीच है और 191 , यह "कक्षा बी" से संबंधित है। इसका मतलब है कि इसकी नेटवर्क आईडी 130.12 है , और इसकी होस्ट आईडी 204.5 है . आइए इसे "पता संख्या 1" के रूप में चिह्नित करें। <पी> क्या यह पता और निम्नलिखित पता (2) एक ही नेटवर्क से संबंधित हैं? (2) 130.90.2.40
<पी> नहीं, चूँकि उनके पास अलग-अलग नेटवर्क पहचानकर्ता हैं, वे एक ही नेटवर्क में नहीं हैं। <पी> निम्नलिखित पता किस वर्ग से संबंधित है? (3) 200.1.1.9
<पी> यह वर्ग सी से संबंधित है, क्योंकि इसके पहले बाइट का मान, 200 है , 192 के बीच है और 223 . इसका मतलब है कि इसका नेटवर्क पहचानकर्ता 200.1.1 है , और इस उपसर्ग से शुरू होने वाला कोई भी पता उसी नेटवर्क में रहेगा। यह विशिष्ट पता होस्ट 9 का वर्णन करता है इस नेटवर्क के भीतर. <पी> चित्र को पूरा करने के लिए, 224 के बीच मान से शुरू होने वाले पते और 239 "क्लास डी" से संबंधित हैं - अर्थात, मल्टीकास्ट पते - पते जो कई उपकरणों से संबंधित हैं। 240 के बीच मान से शुरू होने वाले पते और 255 भविष्य में उपयोग के लिए आरक्षित थे। 0 से शुरू होने वाले पते विशेष पते हैं. आईपी एड्रेस असाइनमेंट
<पी> प्रारंभिक इंटरनेट में, IPv4 पते इंटरनेट असाइन्ड नंबर्स अथॉरिटी (IANA) द्वारा संगठनों को सौंपे गए थे। जैसे-जैसे इंटरनेट का विकास हुआ, यह जिम्मेदारी पांच क्षेत्रीय इंटरनेट रजिस्ट्रियों (आरआईआर) को वितरित की गई जो विभिन्न भौगोलिक क्षेत्रों के लिए पता आवंटन का काम संभालती हैं। बड़े संगठनों को उनकी ज़रूरतों के आधार पर पतों के ब्लॉक प्राप्त होंगे, पता वर्ग इन ब्लॉकों का आकार निर्धारित करेंगे। यहां क्या नुकसान हैं? 🤔
<पी> जबकि क्लासफुल एड्रेसिंग निश्चित-लंबाई दृष्टिकोण की तुलना में अधिक लचीलेपन की अनुमति देता है, यहां तक कि यह दृष्टिकोण भी पर्याप्त लचीला नहीं है। <पी> इस परिदृश्य पर विचार करें:केवल दो संस्थापकों वाली एक छोटी स्टार्टअप कंपनी को एक नेटवर्क पहचानकर्ता की आवश्यकता होती है। उन्हें किस वर्ग की आवश्यकता होगी? <पी> क्लास ए या क्लास बी प्राप्त करना अत्यधिक होगा, इसलिए उन्हें क्लास सी मिल सकती है - 256 की अनुमति पते. यह वर्तमान में आवश्यकता से अधिक है, लेकिन कुछ विस्तार की अनुमति देता है। यदि स्टार्टअप 256 से अधिक हो जाए तो क्या होगा कर्मचारी (और उपकरण)? <पी> इस बिंदु पर, उन्हें क्लास बी पता प्राप्त करने की आवश्यकता होगी, जो 65,536 से कम न हो पते, जब उन्हें केवल 256 से थोड़ा अधिक की आवश्यकता होती है पते. इसका मतलब है 60,000 से अधिक बर्बाद करना पते. <पी> 1990 के दशक की शुरुआत में यह एक वास्तविक समस्या बन गई क्योंकि इंटरनेट तेजी से बढ़ रहा था। अधिक IP पतों की आवश्यकता स्पष्ट हो गई, और IPv4 पता स्थान की आसन्न समाप्ति हुई। ऐसे मामले जहां 60,000 पते बर्बाद किए गए, अब बर्दाश्त नहीं किया जा सकता। CIDR:क्लासलेस इंटरडोमेन रूटिंग
<पी> पतों की इस कमी को संभालने के उपायों में से एक 1993 में क्लासफुल एड्रेसिंग को त्यागना और सीआईडीआर - क्लासलेस इंटरडोमेन रूटिंग नामक एक अन्य दृष्टिकोण पर स्विच करना था। यह दृष्टिकोण आज भी प्रयोग किया जाता है। <पी> नेटवर्क आईडी और होस्ट आईडी चुनते समय सीआईडीआर लचीलेपन की अनुमति देता है। यह नेटवर्क प्रशासकों को कक्षा ए, बी, या सी तक सीमित रहने के बजाय बिल्कुल सही आकार के सबनेट बनाने की सुविधा देता है। <पी> आइए एक सरल उदाहरण से शुरू करें। सीआईडीआर नोटेशन में, हम एक प्रत्यय जोड़ते हैं जो दर्शाता है कि नेटवर्क भाग के लिए कितने बिट्स का उपयोग किया जाता है: (4) 200.8.3.1/16
<पी> यह स्लैश नोटेशन निर्दिष्ट करता है कि कितने बिट्स नेटवर्क आईडी का वर्णन करते हैं। उपरोक्त उदाहरण (4) में, पहला 16 बिट्स (या 2 बाइट्स) का उपयोग नेटवर्क आईडी के लिए किया जाता है। तो, इस मामले में, 200.8 नेटवर्क पहचानकर्ता है, और 3.1 होस्ट पहचानकर्ता है. तथ्य यह है कि 200.8 नेटवर्क आईडी का मतलब है कि सभी पते 200.8.0.0 से हैं 200.8.255.255 के माध्यम से इस नेटवर्क में हैं. <पी> 
<पी> इन अतिरिक्त पतों पर विचार करें: (5) 200.2.13.5
(6) 200.8.21.6
<पी> 16 का यह पता उपसर्ग दिया गया है बिट्स, या 2 बाइट्स, इनमें से कौन सा पता उदाहरण (4) (200.8.3.1/16) के समान नेटवर्क से संबंधित है )? <पी> पहला पता (5) (200.2.13.5 ) इस नेटवर्क से संबंधित नहीं है, क्योंकि इसका पहला 16 है बिट्स - 200.2 , पहले 16 से भिन्न हैं उदाहरण पते के अंश. <पी> दूसरा पता (6) (200.8.21.6 ) उदाहरण पते के समान नेटवर्क से संबंधित है। <पी> 
वास्तविक दुनिया का उदाहरण
<पी> व्यवहार में, एक आईएसपी को 104.16.0.0/12 जैसा बड़ा ब्लॉक प्राप्त हो सकता है आरआईआर से. इससे उन्हें 104.16.0.0 से सभी पतों पर नियंत्रण मिल जाता है 104.31.255.255 पर . इसके बाद आईएसपी ग्राहकों को छोटे सबनेट आवंटित कर सकता है, जैसे कि एक छोटे व्यवसाय को /24 देना 256 के साथ सबनेट पते, या एक बड़ी कंपनी a /20 4,096 के साथ सबनेट पते. सबनेट मास्क
<पी> नेटवर्क उपसर्ग को व्यक्त करने का दूसरा तरीका सबनेट मास्क का उपयोग करना है, जैसे: 255.255.0.0
<पी> बाइनरी में परिवर्तित होने पर, 255 दशमलव में आठ 1 के बराबर है s बाइनरी में है - इसलिए सभी बिट्स चालू हैं। इसलिए यदि आप इस मास्क का बाइनरी में अनुवाद करते हैं, तो आपको यह मिलता है: 11111111 11111111 00000000 00000000
<पी> दूसरे शब्दों में, 16 बिट्स चालू हैं, जिसका अर्थ है 16 का नेटवर्क उपसर्ग बिट्स दोनों सम्मेलनों (सीआईडीआर नोटेशन और सबनेट मास्क) का उपयोग बहुत बार किया जाता है। <पी> 
<पी> सीआईडीआर के साथ, एक पता विभिन्न नेटवर्क उपसर्गों, या सबनेट मास्क दिए जाने पर विभिन्न नेटवर्क में रह सकता है। यदि आप एक ही उदाहरण पते को भिन्न उपसर्ग के साथ मानते हैं, तो 8 कहें बिट्स - दोनों अतिरिक्त पते एक ही नेटवर्क से संबंधित होंगे, क्योंकि वे सभी पहले 8 को साझा करते हैं बिट्स - 200 . <पी> आप 8 का नेटवर्क उपसर्ग कैसे प्रस्तुत करेंगे सबनेट मास्क के रूप में बिट्स? आपको पहले 8 की आवश्यकता है बिट्स चालू होना चाहिए, तो इसका मतलब है 255 दशमलव में, और शेष बिट्स बंद हैं, जिसके परिणामस्वरूप यह सबनेट मास्क है: 255.0.0.0
<पी> 
<पी> यदि आप 24 के नेटवर्क उपसर्ग का उपयोग करते हैं तो क्या होता है बिट्स? सबसे पहले, आप इसे सबनेट मास्क के रूप में कैसे व्यक्त करेंगे? आपको 24 की आवश्यकता है बिट्स को चालू करना है, यानी 3 गुना 8 बिट्स को चालू करना है, जिसके परिणामस्वरूप: 255.255.255.0
<पी> 
<पी> अब, कोई भी अतिरिक्त पता उदाहरण पते के समान नेटवर्क में नहीं रहता है, क्योंकि वे इसकी नेटवर्क आईडी 200.8.3 साझा नहीं करते हैं। . <पी> 
<पी> ध्यान दें कि नेटवर्क उपसर्गों को पूर्ण बाइट्स का प्रतिनिधित्व करने की आवश्यकता नहीं है। उदाहरण के लिए, आप 12 के नेटवर्क उपसर्ग का उपयोग कर सकते हैं बिट्स, या 11 बिट्स, या 22 बिट्स जब उपसर्ग की लंबाई 8 का गुणज न हो , सबनेट मास्क का मान 0 के अलावा कोई और होगा या 255 इसकी एक स्थिति में। <पी> यह स्टार्टअप कंपनी से संबंधित मुद्दे का समाधान करता है। यदि किसी स्टार्टअप के पास 300 है कर्मचारियों, उन्हें 23 प्राप्त करने की आवश्यकता होगी -बिट्स नेटवर्क आईडी, 9 को छोड़कर उनके नेटवर्क के भीतर मेजबानों के लिए बिट्स। इसका मतलब है 2^9, या 512 पते, जो पर्याप्त होने चाहिए। अंतरिम सारांश - IPv4 पते
<पी> इस अनुभाग में, आपने IPv4 पतों के बारे में सीखा है। आईपी पते पदानुक्रमित, तार्किक पते हैं जिनमें 4 शामिल होते हैं बाइट्स IP पते के दो भाग होते हैं:एक नेटवर्क पहचानकर्ता जो नेटवर्क में सभी होस्ट से संबंधित होता है, और एक होस्ट पहचानकर्ता जो नेटवर्क में विशिष्ट होस्ट की पहचान करता है। <पी> आपने नेटवर्क पहचानकर्ता और होस्ट पहचानकर्ता निर्धारित करने के लिए विभिन्न विकल्प तलाशे हैं: - <पी> निश्चित-लंबाई दृष्टिकोण - बहुत कठोर और सीमित
- <पी> क्लासफुल एड्रेसिंग दृष्टिकोण - बेहतर लेकिन फिर भी बेकार
- <पी> सीआईडीआर (क्लासलेस इंटरडोमेन रूटिंग) - लचीला और कुशल
<पी> सीआईडीआर अधिक लचीलापन प्रदान करता है और आईपीवी4 एड्रेस की कमी की महत्वपूर्ण समस्या को दूर करने में मदद करता है। हालाँकि, NAT (नेटवर्क एड्रेस ट्रांसलेशन) और अंततः IPv6 सहित अन्य समाधानों के साथ, CIDR IPv4 पतों की कमी को दूर करने का केवल एक हिस्सा है। <पी> अगला अनुभाग विशेष IPv4 पतों का पता लगाएगा और फिर IPv4 पैकेट के हेडर की जांच करेगा। खुद को परखें
<पी> अब आपके द्वारा सीखी गई अवधारणाओं का अभ्यास करें और सुनिश्चित करें कि आप उनके साथ सहज महसूस करते हैं। <पी> उत्तरों की जाँच करने से पहले निम्नलिखित प्रश्नों के उत्तर देने का प्रयास करने के लिए कुछ समय निकालें। प्रीफिक्स नोटेशन और सबनेट मास्क के बीच कनवर्ट करना
<पी> आप 16 के नेटवर्क उपसर्ग का प्रतिनिधित्व कैसे करेंगे बिट्स, इस प्रकार लिखे गए हैं /16 , एक सबनेट मास्क के रूप में? <पी> आपको 16 की आवश्यकता है बिट्स जो चालू हैं। जब 8 बिट्स चालू हैं आपको 255 मिलता है दशमलव में, इसलिए आप इसका उपयोग करेंगे: 255.255.0.0
<पी> 
<पी> इस नेटवर्क उपसर्ग को देखते हुए, क्या ये पते एक ही नेटवर्क के हैं? <पी> 
<पी> हां, वे ऐसा करते हैं, क्योंकि वे समान सबसे महत्वपूर्ण 16 साझा करते हैं बिट्स, या दो बाइट्स <पी> 
<पी> क्या यह पता पिछले पते के समान नेटवर्क से संबंधित है? <पी> 
<पी> हाँ, ऐसा होता है। फिर, यह वही दो सबसे महत्वपूर्ण बाइट्स साझा करता है। <पी> 
<पी> इस बारे में क्या? क्या यह पिछले पते के समान नेटवर्क से संबंधित है? <पी> 
<पी> नहीं, क्योंकि पहले दो बाइट्स 42.31 नहीं हैं - यह एक अलग नेटवर्क है. तो यह पता होस्ट 1.2 का वर्णन करता है , नेटवर्क के भीतर 42.32 . <पी> 
सबनेट मास्क के साथ पीछे की ओर काम करना
<पी> आइए दूसरी तरह से प्रयास करें। आपके पास यह सबनेट मास्क है: 255.255.255.0
<पी> आप इसे नेटवर्क उपसर्ग का उपयोग करके कैसे व्यक्त करेंगे? <पी> आपके पास 255 की तीन घटनाएँ हैं , जिसका मतलब तीन गुना 8 है बिट्स जो चालू हैं, तो कुल मिलाकर आपके पास 24 है बिट्स जो चालू हैं। तो आप /24 भी लिख सकते हैं . इसका मतलब 3 है बाइट्स. <पी> 
<पी> इस सबनेट मास्क को देखते हुए, क्या उपरोक्त पते (1) और (3) एक ही नेटवर्क से संबंधित हैं? <पी> 
<पी> वे ऐसा करते हैं, क्योंकि उन दोनों के सबसे महत्वपूर्ण तीन बाइट्स समान हैं - नेटवर्क 42.31.93 . <पी> 
<पी> पते (1) और (2) के बारे में क्या? <पी> 
<पी> इस नेटवर्क उपसर्ग को देखते हुए, वे एक ही नेटवर्क से संबंधित नहीं हैं। पहला पता नेटवर्क 42.31.93 का है , और दूसरा पता नेटवर्क 42.31.1 का है . <पी> 
गैर-बाइट-संरेखित उपसर्ग
<पी> नेटवर्क उपसर्गों को 8 पर संरेखित करने की आवश्यकता नहीं है बिट्स, या पूर्ण बाइट्स। मान लीजिए कि आपके पास 14 का नेटवर्क उपसर्ग है बिट्स आप उसे सबनेट मास्क में कैसे परिवर्तित करेंगे? <पी> खैर, पहला बाइट स्पष्ट है:आपके पास 8 है बिट्स चालू है, इसलिए पहला बाइट 255 है . अगले के बारे में क्या? <पी> बाइनरी में, आप छह अतिरिक्त 1 और फिर 2 0 चाहते हैं - इसलिए बाइनरी में आप लिखेंगे: 11111100
<पी> दशमलव में परिवर्तित करने पर, यह बाइनरी संख्या 252 का प्रतिनिधित्व करती है . तो आपका सबनेट मास्क है: 255.252.0.0
<पी> इस रूपांतरण को करने का दूसरा तरीका:आप जानते हैं कि बाइनरी में आठ 1 255 को दर्शाते हैं दशमलव में. आप यह भी जानते हैं कि 11 बाइनरी में 3 है , तो आप आसानी से 3 घटा सकते हैं 255 से और 252 प्राप्त करें . <पी> 
<पी> इसके बाद, दूसरे तरीके से प्रयास करें। आपके पास निम्नलिखित सबनेट मास्क है: 255.255.224.0
<पी> कितने बिट नेटवर्क उपसर्ग का प्रतिनिधित्व करते हैं? <पी> पहले दो बाइट्स स्पष्ट हैं:आपके पास 16 है बिट्स तीसरी बाइट को बाइनरी में परिवर्तित करना:224 दशमलव में 11100000 है बाइनरी में. इसका मतलब है कि आपके पास अतिरिक्त तीन 1 हैं, इसलिए आप उपरोक्त सबनेट मास्क को /19 के उपसर्ग के रूप में लिख सकते हैं। बिट्स - 16 दो 255 के लिए बिट्स बाइट्स, और 3 224 के लिए अतिरिक्त बिट्स बाइट. <पी> 
नेटवर्क सदस्यता का निर्धारण
<पी> आइए निम्नलिखित पतों पर विचार करें: <पी> 
<पी> क्या वे एक ही नेटवर्क का हिस्सा हैं? 🤔 <पी> यह सबनेट मास्क पर निर्भर करता है। <पी> यदि नेटवर्क उपसर्ग /8 है , तो वे एक ही नेटवर्क का हिस्सा हैं, क्योंकि वे एक ही नेटवर्क आईडी साझा करते हैं। <पी> 
<पी> दूसरी ओर, यदि नेटवर्क उपसर्ग /16 है , तो उनके पास अलग-अलग नेटवर्क आईडी हैं, और इस प्रकार वे एक ही नेटवर्क से संबंधित नहीं हैं। लेकिन बीच में उपसर्गों से क्या होता है? क्या वे /9 के उपसर्ग के लिए एक ही नेटवर्क में रहेंगे ? /14 ? <पी> इस प्रश्न से निपटने का तरीका इन पतों की दूसरी बाइट को बाइनरी में परिवर्तित करना है। पहले पते के लिए, यह बाइट 24 है , जो बाइनरी में है: 00011000
<पी> दूसरे पते के लिए, दूसरा बाइट 23 है , जो बाइनरी में है: 00010111
<पी> 
<पी> आप देख सकते हैं कि सबसे महत्वपूर्ण 4 दूसरे बाइट के भीतर बिट्स समान हैं। यदि आप पहला 8 जोड़ते हैं पते के बिट्स, आप देखते हैं कि सबसे महत्वपूर्ण 12 इन पतों के अंश समान हैं। <पी> इसलिए, यदि आपके पास /11 का नेटवर्क उपसर्ग है , क्या ये पते एक ही नेटवर्क के हैं? <पी> हाँ, वे करते हैं - उनका सबसे महत्वपूर्ण 11 बिट्स समान हैं. <पी> /13 के बारे में क्या? ? <पी> नहीं, इस नेटवर्क उपसर्ग के साथ, वे अपने 13 के समान नेटवर्क पहचानकर्ता साझा नहीं करते हैं वां बिट अलग है। <पी> इस अभ्यास से आपको सबनेट मास्क और नेटवर्क प्रीफ़िक्स के साथ सहज महसूस करने में मदद मिलेगी। अगले अनुभाग में, आप विशेष आईपी पते के बारे में जानेंगे और फिर आईपी पैकेट के हेडर की जांच करेंगे। विशेष IPv4 पते
<पी> अब जब आप आईपी पते और सबनेट मास्क के साथ सहज हो गए हैं, तो आइए कुछ आईपी पते तलाशें जिनके विशेष अर्थ हैं। "यह होस्ट" पता:0.0.0.0
<पी> पता 0.0.0.0 इसका अर्थ है "यह होस्ट" और इसका उपयोग दो परिदृश्यों में किया जाता है: <पी> सबसे पहले, जब कोई मशीन बूट होती है और उसके पास अभी तक कोई आईपी पता नहीं होता है। आईपी पते तार्किक पते होते हैं जिन्हें किसी मशीन को निर्दिष्ट करने की आवश्यकता होती है। इस असाइनमेंट से पहले, किसी डिवाइस का कोई IP पता नहीं होता है। यदि डिवाइस को इस स्तर पर संचार करने की आवश्यकता है, तो वह इस विशेष पते, 0.0.0.0 का उपयोग कर सकता है . <पी> दूसरा, नेटवर्क एप्लिकेशन लिखते समय जिन्हें सभी नेटवर्क इंटरफेस पर आने वाले कनेक्शनों को सुनने की आवश्यकता होती है। उदाहरण के लिए, यदि किसी मशीन में दो इंटरफेस हैं - एक आईपी एड्रेस 1.1.1.1 के साथ , और दूसरा 2.2.2.2 पते के साथ - 0.0.0.0 पते पर सुन रहा हूं इसका अर्थ है कनेक्शन स्वीकार करना, भले ही कोई भी नेटवर्क इंटरफ़ेस उन्हें प्राप्त करता हो। "यह नेटवर्क" पते
<पी> विशेष पतों का एक अन्य वर्ग वे हैं जो शून्य से शुरू होते हैं, जहां शून्य का अर्थ है "यह नेटवर्क।" <पी> उदाहरण के लिए, यदि आपके पास पते वाली एक मशीन है: 12.34.55.55
<पी> और 16 का एक नेटवर्क उपसर्ग बिट्स, यह मशीन अपने पूरे पते का उपयोग करके नेटवर्क पर किसी अन्य डिवाइस पर एक पैकेट भेज सकती है, उदाहरण के लिए 12.34.66.66 , या वैकल्पिक रूप से विशेष शून्य संकेतन का उपयोग करें और पैकेट को यहां भेजें: 0.0.66.66
<पी> इसका मतलब है "होस्ट 66.66 को एक पैकेट भेजें इस नेटवर्क पर।" निःसंदेह, प्राप्तकर्ता को इस पते की सही व्याख्या करने के लिए संबंधित नेटवर्क उपसर्ग को भी जानना चाहिए। प्रसारण पते
<पी> पता 255.255.255.255 , जहां सभी बिट्स 1 पर सेट हैं , स्थानीय नेटवर्क में सभी होस्टों का पता है - प्रसारण पता। यह ईथरनेट (FF:FF:FF:FF:FF:FF) में प्रसारण पते के समान है ). दोनों ही मामलों में, सभी बिट्स 1 पर सेट हैं . <पी> एक उचित नेटवर्क पहचानकर्ता का उपयोग करना जहां होस्ट पहचानकर्ता 1s पर सेट है, का उपयोग दूरस्थ नेटवर्क पर प्रसारण पैकेट भेजने के लिए किया जा सकता है। उदाहरण के लिए, एक नेटवर्क 12.34.0.0/16 पर विचार करें और 12.35.0.0/16 की नेटवर्क आईडी वाला एक अन्य नेटवर्क . यदि कोई मशीन 12.34.55.55 पर है अन्य नेटवर्क के सभी उपकरणों पर एक पैकेट भेजना चाहता है, यह गंतव्य पते का उपयोग कर सकता है:12.35.255.255 . <पी> भले ही आईपी विनिर्देश (आरएफसी) के अनुसार इसकी अनुमति है, व्यवहार में यह सुविधा अक्सर अक्षम हो जाती है क्योंकि यह सुरक्षा कमजोरियां पैदा कर सकती है। लूपबैक पते:127.0.0.0/8
<पी> नेटवर्क में सभी पते 127.0.0.0/8 (अर्थात, वे सभी पते जो 127 से शुरू होते हैं ) लूपबैक पते हैं। इनमें से किसी भी पते पर भेजे गए पैकेट को भौतिक नेटवर्क पर नहीं डाला जाता है, बल्कि ऑपरेटिंग सिस्टम के भीतर स्थानीय रूप से संसाधित किया जाता है। यह विकास और डिबगिंग के लिए बेहद उपयोगी है। <पी> उदाहरण के लिए, एक साधारण चैट प्रोग्राम विकसित करते समय, आपको डेटा का आदान-प्रदान करने वाले दो क्लाइंट की आवश्यकता होती है। एक दृष्टिकोण दो अलग-अलग भौतिक कंप्यूटरों का उपयोग करना होगा, लेकिन यह थकाऊ है - आपको एक कंप्यूटर पर एक संदेश लिखना होगा, दूसरे कंप्यूटर की जांच करके देखना होगा कि यह प्राप्त हुआ है या नहीं, फिर दूसरे कंप्यूटर पर एक संदेश लिखें, और रसीद को सत्यापित करने के लिए पहले कंप्यूटर पर वापस जाएं। <पी> लूपबैक पते का उपयोग करना एक बहुत ही सरल तरीका है। दोनों क्लाइंट एक ही मशीन पर चल सकते हैं और एक दूसरे से जुड़ सकते हैं। आप एक ही भौतिक कंप्यूटर पर दो अलग-अलग क्लाइंट प्रोग्राम चला सकते हैं और अतिरिक्त मशीन की आवश्यकता के बिना उनके बीच संदेशों का आदान-प्रदान कर सकते हैं। <पी> उदाहरण के लिए, आप पते 127.0.0.1 का उपयोग कर सकते हैं , एक ग्राहक पोर्ट 1337 पर सुन रहा है और दूसरा पोर्ट 1338 पर . जब क्लाइंट A क्लाइंट B को एक पैकेट भेजता है, तो यह पैकेट आपके नेटवर्क कार्ड को कभी नहीं छोड़ता बल्कि ऑपरेटिंग सिस्टम के भीतर ही रहता है। क्लाइंट बी लूपबैक इंटरफ़ेस से पैकेट प्राप्त करता है जैसे कि यह भौतिक नेटवर्क से प्राप्त किया गया हो। <पी> डिबगिंग पूरी होने के बाद, आपके क्लाइंट कोड को बदलने की आवश्यकता नहीं है - एकमात्र अंतर यह है कि वे लूपबैक पते के बजाय वास्तविक आईपी पते का उपयोग करके संचार करेंगे। <पी> 
विशेष IPv4 पतों का सारांश
<पी> उन विशेष IPv4 पतों को संक्षेप में प्रस्तुत करने के लिए जिनके बारे में आपने सीखा है: विशेष पता अर्थ उपयोग 0.0.0.0 "यह होस्ट" बूट के दौरान या 0 से शुरू होने वाले सभी इंटरफ़ेस पतों को सुनने के लिए उपयोग किया जाता है "यह नेटवर्क" स्थानीय नेटवर्क255.255.255.255 पर होस्ट को भेजा जा रहा है प्रसारणस्थानीय नेटवर्क पर सभी होस्टों को भेजा जा रहा है, होस्ट भाग में सभी 1 के साथ नेटवर्क आईडी भेजा जा रहा है, निर्देशित प्रसारण किया जा रहा है, एक विशिष्ट नेटवर्क पर सभी होस्टों को भेजा जा रहा है 127.0.0.0/8 भौतिक नेटवर्क का उपयोग किए बिना लूपबैक परीक्षण और डिबगिंग <पी> अगले भाग में, आप IPv4 हेडर की संरचना के बारे में जानेंगे। <पी> अब जब आप आईपी पते, सबनेट और विशेष पते को समझ गए हैं, तो आईपीवी4 हेडर संरचना की विस्तार से जांच करने का समय आ गया है। <पी> 
<पी> उपरोक्त चित्र RFC 791 में परिभाषित IPv4 के हेडर को दर्शाता है। आइए प्रत्येक फ़ील्ड की जाँच करें: संस्करण (4 बिट्स)
<पी> 
<पी> हेडर संस्करण फ़ील्ड से शुरू होता है, जिसमें चार बिट होते हैं। IPv4 पैकेट के लिए, संस्करण 4 है , इसलिए इस फ़ील्ड में हमेशा 4 का मान रहेगा (या 0100 बाइनरी में). <पी> ❓ हेडर संस्करण फ़ील्ड से क्यों शुरू होता है? 🤔 <पी> (ध्यान दें - जब मैं ❓चिह्न के साथ एक वाक्य शुरू करता हूं - यह आपके लिए एक प्रश्न है, और मैं आपको आगे पढ़ने से पहले इसका उत्तर देने का प्रयास करने के लिए प्रोत्साहित करता हूं)। <पी> कारण यह है कि शेष फ़ील्ड संस्करण के अनुसार भिन्न हो सकते हैं। यदि कोई नेटवर्क डिवाइस एक आईपी पैकेट पढ़ता है और संस्करण फ़ील्ड में 4 का मान होता है , यह उम्मीद करेगा कि पैकेट का शेष हिस्सा IPv4 संरचना का पालन करेगा। यदि इसमें कोई अन्य मान है, जैसे 6 , शेष फ़ील्ड भिन्न हैं, जैसे IPv6 में। <पी> 
<पी> यह फ़ील्ड हेडर की लंबाई को ही इंगित करता है। <पी> ❓ हमें लंबाई निर्दिष्ट करने की आवश्यकता क्यों है? 🤔 <पी> ईथरनेट के विपरीत, जहां हेडर का आकार तय होता है, आईपीवी4 हेडर की लंबाई वैकल्पिक फ़ील्ड के कारण भिन्न हो सकती है। विशेष विकल्पों के बिना आईपी पैकेट के लिए, हेडर में 20 होता है बाइट्स, जो सबसे आम मामला है। <पी> IHL फ़ील्ड लंबाई को सीधे बाइट्स में निर्दिष्ट नहीं करता है, बल्कि 4-बाइट शब्दों की इकाइयों में निर्दिष्ट करता है। तो 20 की लंबाई निर्दिष्ट करने के लिए बाइट्स, मान 5 होगा (5 × 4 =20). यह एन्कोडिंग फ़ील्ड को 60 तक हेडर लंबाई निर्दिष्ट करते समय केवल 4 बिट्स का उपयोग करने की अनुमति देती है। बाइट्स (जब IHL =15 ). <पी> इसलिए एक सामान्य IPv4 पैकेट बाइट 0x45 से शुरू होता है हेक्साडेसिमल में, अर्थात यह संस्करण 4 है आईपी प्रोटोकॉल का, और हेडर 20 है बाइट्स लंबे. सेवा का प्रकार (टीओएस) (8 बिट्स)
<पी> 
<पी> इस क्षेत्र के पीछे विचार यह है कि सभी पैकेट समान रूप से महत्वपूर्ण नहीं हैं। हो सकता है कि आप कुछ पैकेटों को दूसरों की तुलना में प्राथमिकता देना चाहें। <पी> उदाहरण के लिए, वास्तविक समय डेटा (जैसे आवाज या वीडियो कॉन्फ्रेंसिंग) ले जाने वाले पैकेट ईमेल या फ़ाइल डाउनलोड ले जाने वाले पैकेट की तुलना में अधिक समय-संवेदनशील होते हैं। यदि कोई राउटर वर्तमान में उच्च लोड का अनुभव कर रहा है, तो उसे आदर्श रूप से समय-संवेदनशील पैकेट को प्राथमिकता देनी चाहिए। <पी> सेवा का प्रकार फ़ील्ड प्रेषकों को उनके पैकेट की प्राथमिकता इंगित करने की अनुमति देता है। हालाँकि, सार्वजनिक इंटरनेट पर, इस फ़ील्ड को अक्सर राउटर्स द्वारा अनदेखा कर दिया जाता है क्योंकि कोई भी प्रेषक कोई भी प्राथमिकता मान निर्धारित कर सकता है। अधिकांश मामलों में, इस फ़ील्ड में 0 का मान होता है . कुल लंबाई (16 बिट्स)
<पी> 
<पी> यह फ़ील्ड आईपी पैकेट की कुल लंबाई निर्दिष्ट करती है, जिसमें हेडर और पेलोड (डेटा) दोनों शामिल हैं। <पी> ❓ लंबाई निर्दिष्ट करने के लिए इसकी आवश्यकता क्यों है? 🤔 <पी> Unfortunately, the IP layer doesn’t necessarily know if some of the bytes in the packet are actually a padding of the second layer. I described this in detail in a previous post, where I showed that in Ethernet protocol, in some cases, the receiving Ethernet entity cannot tell which bytes belong to the payload and which bytes are simply padding. The IP layer needs to know precisely which bytes belong to the actual packet, hence the Total Length field. <पी> ❓What is the maximum size of an IPv4 packet? 🤔 <पी> Since this field is 16 bits long, an IPv4 packet may contain a maximum of 2^16-1 bytes, or 65,535 bytes, including the header. The minimum size is 20 bytes, consisting of just the header without options or payload. Fragmentation Fields (32 bits)
<पी> 
<पी> The next four bytes are dedicated to fragmentation control. I’ll cover these fields in a separate section, as they involve a complex topic deserving special attention. Time to Live (8 bits)
<पी> 
<पी> Despite its name, this field doesn't actually measure time but rather the maximum number of routing hops a packet can traverse before being discarded. <पी> To understand its purpose, consider this scenario:If Machine A sends a packet to Machine B through a series of routers, but there's a routing loop where Router 2 sends to Router 3, which sends to Router 4, which sends back to Router 2, the packet could circulate indefinitely, consuming bandwidth and never reaching its destination. <पी> 
<पी> The TTL field prevents this by setting a limit on how many hops a packet can take: - <पी> The sender sets an initial TTL value (often
64 or 128 )
- <पी> Each router that handles the packet decrements the TTL by
1
- <पी> If a router receives a packet with TTL =
1 , it decrements it to 0 and discards the packet
- <पी> The router then sends an ICMP "Time Exceeded" message back to the original sender
<पी> This doesn't solve the underlying problem of routing loops, but it prevents packets from circulating forever. <पी> In IPv6, this field is renamed "Hop Limit," which more accurately describes its function. Protocol (8 bits)
<पी> 
<पी> This field describes the payload of the IPv4 packet. उदाहरण के लिए: - <पी> A value of
6 means the payload is TCP
- <पी> A value of
17 means the payload is UDP
<पी> This helps the receiving system know which protocol handler should process the packet's contents. It's similar to the Type field in Ethernet, which specifies the protocol of the layer encapsulated within the Ethernet frame. <पी> 
<पी> This is a 16-bit checksum used to verify the validity of the header only (that is, excluding the payload). The sender computes this value based on the fields of the header, and the receiver also computes it to validate that the header was received correctly. <पी> ❓The checksum must be recalculated by each router. ऐसा क्यों? 🤔 <पी> Because the TTL field changes at each hop. For example, if a packet starts with TTL =7 , each router will: - <पी> Verify the current checksum based on TTL =
7
- <पी> Decrement TTL to
6
- <पी> Calculate a new checksum based on TTL =
6
- <पी> Forward the packet with the new checksum
<पी> If the checksum verification fails, the device drops the packet. This prevents packets with corrupted headers (which might have incorrect destination addresses, for instance) from being forwarded. Source and Destination Addresses (32 bits each)
<पी> 
<पी> These fields contain the source and destination IPv4 addresses, respectively. Each is 4 bytes (32 bits) long, as you learned in the previous sections on IPv4 addressing. Options (Variable Length)
<पी> 
<पी> Most IPv4 packets don't include options, but when present, they can provide additional functionality: - <पी> Record Route :Each router that handles the packet adds its own address to this option, creating a trace of the packet's path
- <पी> Source Routing :Allows the sender to specify the route the packet should take:
- <पी> Strict Source Routing:The entire route must be followed exactly
- <पी> Loose Source Routing:Certain routers must be traversed, but the exact path between them is flexible
Padding
<पी> In some cases, the header ends with padding bytes (usually 0 s). <पी> ❓Why does the IPv4 header have padding?🤔 <पी> As explained before, the IHL field specifies the header length in 4-byte units, so the total header length must be a multiple of 4 bytes. If options make the header length not divisible by 4, padding bytes (usually 0 ) are added to reach the next multiple of 4. <पी> For example, if you have 3 bytes of options, you would need 1 byte of padding to make the total header length a multiple of 4 bytes. <पी> You've now learned about the structure of the IPv4 header, with the exception of the fragmentation fields which I’ll cover in the next section. <पी> The IPv4 header efficiently packs all the necessary routing and control information into a compact structure, typically 20 bytes long (without options). This design allows for fast processing by routers while providing the flexibility needed for internet communication. It is amazing how prominent IPv4 is, even so many years after its publication. <पी> In the next section, you'll learn about IPv4 fragmentation. IPv4 Fragmentation
<पी> In the previous section, you learned about most of the IPv4 header structure, with the exception of 32 bits dedicated to fragmentation. This topic deserves special attention, as it reveals important aspects of how IP packets travel across different networks. <पी> Why Fragmentation Is Needed
<पी> To understand what fragmentation is and why it's needed, consider the following network scenario: <पी> 
<पी> In this diagram, you have two different networks where Machine A resides in one network and Machine B resides in another. A router forwards packets between these two networks. <पी> These two networks have different Maximum Transmission Units (MTUs). MTU refers to the maximum size of a frame that can be transmitted in a network. उदाहरण के लिए: - <पी> Machine B is connected to an Ethernet network with an MTU of
1500 bytes
- <पी> Machine A is connected to a different network with an MTU of
2000 bytes
<पी> Different MTUs stem from the different protocols and hardware that different networks have. Ethernet has an MTU of 1500 bytes. This maximum size was chosen because RAM was expensive back in the late 1970s when Ethernet was planned, and a receiver would need more RAM if a frame could be bigger. Other networks were devised at different times where RAM prices might have been lower, or just have other considerations that affect the MTU. <पी> Now, consider this scenario:Machine A wants to send a packet to Machine B. This packet is 1800 bytes long. From A's perspective, there's no problem since its network supports packets of this size. Machine A transmits the packet. <पी> When the router receives this packet, it faces a problem:it cannot simply forward the packet to B's network because the packet is too big for the network's MTU. The router must fragment the packet – splitting it into smaller chunks of up to 1500 bytes, which will then be reassembled by Machine B. How Fragmentation Works in IP
<पी> Let's examine the scenario further. The router needs to take an IP packet of 1800 bytes and split it into two fragments, each consisting of up to 1500 bytes. If Machine A sends another packet of 1800 bytes to Machine B, the router will have to split that one too – resulting in four different fragments that will be reassembled into two separate packets. <पी> 
<पी> When Machine B receives these fragments, it must ensure that it reassembles fragment #1 together with fragment #2 of packet A, and fragment #1 with fragment #2 of packet B – and not, for instance, fragment #1 of packet A with fragment #2 of packet B. It must also reassemble the fragments in the correct order – so structure a packet that consists of #1#2 and not #2#1. <पी> 
Identification Field
<पी> First, focus on making sure Machine B reassembles fragments of the same packet (for example, fragment #1 and fragment #2 of packet A in the example above, rather than fragment #1 of packet A and fragment #2 of packet B). This is achieved using the identification field of IPv4. Fragments belonging to the same packet will have the same identification value. For example, both fragments of packet A might have identification set to 100 , and both fragments of packet B might have identification of 200 . <पी> 
<पी> It's important to note that sharing identification values isn't sufficient for fragments to belong to the same packet. Fragments of the same packet must also share: - <पी> The same source IP address
- <पी> The same destination IP address
- <पी> The same protocol value (indicating whether the payload is TCP, UDP, and so on)
Fragment Offset
<पी> Since IP is a connectionless protocol, there's no guarantee that fragments will arrive at Machine B in the correct order. Fragment #2 of packet A may arrive before fragment #1. To handle this issue, each fragment carries an Offset field, which denotes the offset from the beginning of the original packet. <पी> The Offset field consists of 13 bits, which means it can carry values from 0 to 8191 (2^13-1). This poses a potential problem, as the maximum size of an IP packet can be 65,535 bytes (since the Total Length field of the IP header consists of 16 bits). <पी> To address this limitation, the value encoded in the Offset field is actually multiplied by 8 (2^3). This means the minimum size of a fragment is 8 bytes, with the exception of the last fragment. <पी> ❓Why do IP packets carry an offset in bytes divided by 8, instead of just a sequential fragment number?🤔 <पी> While using sequence numbers might seem simpler, it would create problems when packets need to be fragmented multiple times. <पी> For example, if Computer A sends a packet to the first router, which fragments it into pieces of 1480 bytes and 320 bytes, and then these fragments are sent to another router that needs to fragment them again into even smaller pieces, how would you number them? <पी> With byte offsets, the solution is straightforward – if the first fragment has an offset of 0 and the next one has an offset of 1480 , then if we need to split them into maximum 800 -byte fragments, we'd have: - <पी> First fragment:
800 bytes with offset 0
- <पी> Second fragment:
680 bytes with offset 800
- <पी> Third fragment:
320 bytes with offset 1480
More Fragments and Don't Fragment Flags
<पी> When Machine B receives a fragment, it needs to know whether this is an entire packet by itself or if it should expect additional fragments. For this purpose, each IP fragment carries a More Fragments (MF ) bit that is set to 1 for every fragment that is not the last fragment of the packet. For the last fragment, it's set to 0 . <पी> In case the packet consists of a single fragment – the MF bit will be set to 0 , and the offset field will also hold the value 0 (that is, 13 bits of 0 s). <पी> Another bit related to fragmentation is the Don't Fragment (DF ) bit. When this flag is turned on, intermediate devices should not fragment the original packet, even if it exceeds the MTU. Instead, they should drop it and typically send an ICMP "Fragmentation Needed" message back to the source. <पी> In our example, if Machine A sets the Don't Fragment bit to 1 , the router would drop the packet, and notify Machine A about it. <पी> Note that right after the identification field and before the DF flag, there is a reserved bit set to 0 . This bit was reserved in case it is needed in the future, for a reason unknown to the original authors of IPv4. Fragmentation Example
<पी> Consider again our example above – with Machine A residing in a network where the MTU is 2000 , and Machine B residing in a network where the MTU is 1500 . Machine A sends a packet which is 1800 bytes long. <पी> ❓Can you fill the values in these tables? <पी> First Fragment: Total Length IdentificationDon’t FragmentMore FragmentsOffset <पी> Second Fragment: Total Length IdentificationDon’t FragmentMore FragmentsOffset <पी> For our example above, the values of the relevant fragmentation fields in IP would be as follows: <पी> First Fragment: - <पी> Total Length:
1500 (including 20 bytes of IP header, so 1480 bytes of payload)
- <पी> Identification:
1337 (arbitrary value)
- <पी> Don't Fragment bit:
0 (off, to allow further fragmentation if needed)
- <पी> More Fragments bit:
1 (on, as this is not the last fragment)
- <पी> Offset:
0 (it's the first fragment)
<पी> Second Fragment: - <पी> Total Length:
340 (including 20 bytes of IP header, so 320 bytes of payload – together with the first fragment, we get to 1800 bytes of payload)
- <पी> Identification:
1337 (same as first fragment, indicating they belong together)
- <पी> Don't Fragment bit:
0 (off, to allow further fragmentation if needed)
- <पी> More Fragments bit:
0 (off, as this is the last fragment)
- <पी> Offset:
185 (1480/8 =185, or 0xB9 in hexadecimal)
IPv4 Fragmentation – Summary
<पी> You've now learned about the final part of the IPv4 Header:fragmentation. Fragmentation is necessary to allow packets to travel across networks with different MTUs. The IPv4 header includes several fields specifically designed to support fragmentation: - <पी> Identification (16 bits):Identifies which fragments belong together
- <पी> Flags (3 bits):Including the "More Fragments" and "Don't Fragment" flags
- <पी> Fragment Offset (13 bits):Indicates where in the original packet this fragment belongs
<पी> With this knowledge, you now understand every bit and byte of the IPv4 header and how IP packets can traverse networks with different characteristics. Summary – IPv4
<पी> In this comprehensive guide to IPv4, you've learned about the fundamental building blocks of Internet communications. Let's recap the key concepts we covered: Addressing and Network Structure
- <पी> IPv4 addresses are 32-bit numbers typically written in dotted decimal notation
- <पी> Networks can be identified using various methods:
- <पी> Fixed-length approach (historically)
- <पी> Classful addressing (A, B, C, D, E classes)
- <पी> CIDR (modern approach allowing flexible network sizes)
- <पी> Special addresses serve specific purposes:
- <पी>
0.0.0.0 for "this host"
- <पी>
127.0.0.0/8 for loopback
- <पी>
255.255.255.255 for broadcast
- <पी> The header contains crucial fields for packet routing and processing:
- <पी> Version and IHL for header interpretation
- <पी> Type of Service for traffic prioritization
- <पी> Total Length for packet size
- <पी> Various fields for fragmentation control
- <पी> TTL to prevent infinite routing loops
- <पी> Protocol to identify the encapsulated protocol
- <पी> Checksum for error detection
- <पी> Source and destination addresses
Fragmentation
- <पी> Allows IPv4 packets to traverse networks with different MTUs
- <पी> Uses three key fields:
- <पी> Identification to group fragments
- <पी> Flags to control fragmentation
- <पी> Fragment Offset to reassemble packets
Final Words
<पी> While IPv4 has limitations, particularly its address space constraints, its elegant design and robust features have allowed it to remain the backbone of the Internet for over four decades. Understanding IPv4 provides essential context for working with modern networks and helps in transitioning to newer protocols like IPv6. About the Author
<पी> Omer Rosenbaum is Swimm’s Chief Technology Officer. He's the author of the Brief YouTube Channel. He's also a cyber training expert and founder of Checkpoint Security Academy. He's the author of Gitting Things Done (in English) and Computer Networks (in Hebrew). You can find him on Twitter. Additional References
- Computer Networks Playlist - on my Brief channel
<पी> मुफ़्त में कोड करना सीखें. फ्रीकोडकैंप के ओपन सोर्स पाठ्यक्रम ने 40,000 से अधिक लोगों को डेवलपर्स के रूप में नौकरी पाने में मदद की है। आरंभ करें
