वह दुनिया जहाँ IPv6 एक शानदार डिज़ाइन था (2017)

 (apenwarr.ca)
11 पॉइंट द्वारा GN⁺ 9 일 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • शुरुआती नेटवर्क, जो मुख्यतः point-to-point connections पर आधारित थे, में लगभग किसी address system की ज़रूरत नहीं थी, लेकिन लागत घटाने के लिए bus networks के फैलाव से MAC addresses, bridging, ARP जैसी जटिलताएँ जमा होती गईं
  • Ethernet और IP के जुड़ने के बाद next-hop forwarding के लिए MAC addressing और ARP broadcast की ज़रूरत पड़ी, और बड़े interconnected networks तथा wifi में यह बोझ बहुत बढ़ गया
  • IPv6 की कल्पना में physical bus और layer 2 internetwork को छोड़कर broadcast, ARP, DHCP, MAC addresses तक हटा देने वाली एक सरल दुनिया की उम्मीद शामिल थी
  • लेकिन वास्तविक deployment environments में IPv4 और मौजूदा framing बने रहे, इसलिए neighbor discovery, DHCP, NAT, layer 2 bridging जैसी विरासतें भी साथ बनी रहीं
  • चलते-फिरते कनेक्शन को बनाए रखने के लिए Internet routing की बजाय layer 2 bridging और central tunneling अब भी इस्तेमाल होते हैं, और QUIC जैसे विकल्पों को roaming bypass path के रूप में चर्चा में लाया जाता है

bus networks ने सब कुछ कैसे बिगाड़ा

  • टेलीफोन नेटवर्क के शुरुआती circuit switching और leased-line माहौल में केवल point-to-point connections मौजूद थे, इसलिए किसी address system की ज़रूरत नहीं थी; एक ओर डाले गए bits कुछ समय बाद दूसरी ओर निकलते थे
  • TDM और virtual circuit switching आने के बाद भी उपयोगकर्ता के नज़रिए से एक तरफ़ का input दूसरी तरफ़ के output से ही जुड़ा रहता था, इसलिए इस चरण पर भी addresses की आवश्यकता नहीं थी
  • कई interfaces वाले computers जब लाइनों के बीच bits आगे भेजने लगे, तब IP addresses, subnets और routing आए, लेकिन point-to-point links पर तब भी MAC addresses की ज़रूरत नहीं थी
  • local site connections की लागत घटाने के लिए कई devices को एक ही लाइन पर जोड़ने वाले bus networks आए, और Internet परिवार से अलग-अलग अपने layer 2 systems उभर गए
  • शुरुआती LAN arcnet में 8-bit layer 2 addresses को jumpers या DIP switches से manually configure करना पड़ता था; duplicate होने पर गंभीर failures होते थे, लेकिन networks छोटे होने से असुविधा सीमित थी
  • Ethernet ने 48-bit MAC addresses लाकर manufacturing stage पर लगभग unique addresses देने के तरीके से duplicate की समस्या हल की
  • IPX और Netware जैसी LAN technologies एक ही bus network के भीतर बिना address configuration के अच्छी तरह चलती थीं, और इसे सुंदर व भरोसेमंद दौर के रूप में वर्णित किया गया है
  • बड़े enterprise और university networks को single 10 Mbps bus के bottleneck के कारण कई buses को interconnect करना पड़ा, लेकिन उस समय कम mature IP की जगह Ethernet address आधारित bridging और switching को scaling path के रूप में चुना गया
  • Ethernet addresses factory में क्रमिक रूप से दिए जाते थे, इसलिए उनमें hierarchy नहीं थी; इसी वजह से bridging tables को modern IP routing tables की तरह subnet-स्तर पर कुशलता से aggregate नहीं किया जा सकता था
    • efficient bridging के लिए हर MAC address किस bus पर है, यह याद रखना पड़ता था
    • इसे manually configure न करना पड़े, इसलिए automatic learning और complex interactions की ज़रूरत पड़ी
  • जटिल bridge networks spanning tree जैसी तकनीकों पर टिके, जिनके साथ broadcast flood, non-optimal paths और कम debugging visibility जैसी समस्याएँ आईं
  • बीच के bridges में सामान्य Ethernet में address की अवधारणा न होने से traceroute जैसे tools बनाना मुश्किल था, और bridging लगभग non-debuggable संरचना बन गई
  • इसके बावजूद bridging hardware optimization की बदौलत Ethernet line rate के क़रीब बहुत तेज़ चलती थी, और उस समय यह बड़ा फ़ायदा था

bus के ऊपर चलता Internet

  • जब long-distance point-to-point links से individual computers जुड़ते थे, तब धीरे-धीरे पूरे LAN को जोड़ने की ज़रूरत उभरी, और LANs के बीच long-distance connectivity चाहिए थी
  • साधारण long-distance bridging congestion control की समस्याओं के कारण काम नहीं कर सकती थी; Ethernet bridging सिर्फ़ तब काम करती थी जब सभी links की speed लगभग समान हो या congestion बहुत कम हो
  • 10 Mbps Ethernet और 0.128 Mbps point-to-point link को सीधे bridge करना लगभग बेकार था, और flooding आधारित path discovery धीमे links पर बहुत अधिक wasteful थी
  • local environment में किसी तरह सहनीय non-optimal routing भी धीमे और महंगे long-distance links पर घातक थी, इसलिए उसमें scalability नहीं थी
  • यह समस्याओं का वही समूह था जिसे Internet पक्ष पहले से संभाल रहा था, और अगर LAN buses को Internet technologies से जोड़ा जाए तो संरचना कहीं बेहतर हो सकती थी
  • इसलिए Ethernet और arcnet जैसे LANs पर Internet packets ले जाने के लिए frame formats डिज़ाइन किए गए, और यहीं से समस्याएँ शुरू हुईं
  • यदि एक Ethernet segment में कई IP routers हों, तो यह बताना ज़रूरी हो गया कि packet किस router को मिले और आगे बढ़े; केवल अंतिम destination IP से यह चयन व्यक्त नहीं किया जा सकता था
  • इसलिए final destination को IP header में छोड़कर, वास्तविक next-hop router को Ethernet frame के MAC address से निर्दिष्ट करना पड़ा
  • इंसान जिस जानकारी को वास्तव में व्यक्त करना चाहता है, वह destination IP 10.1.1.1 को router MAC 11:22:33:44:55:66 पर भेजो जैसी है, लेकिन operating system इसे router IP 192.168.1.1 के जरिए जैसी form में संभालता है
  • इस abstraction के लिए operating system को पहले router IP का Ethernet address खोजना पड़ता था, और इसी intermediate step के रूप में ARP जोड़ा गया
  • ARP पूरे local Ethernet पर broadcast भेजकर किसी specific IP owner को खोजता है, और अगर bridges हों तो Ethernet broadcast होने के कारण इसे सभी interfaces पर forward करना पड़ता है
  • बड़े interconnected Ethernet में excessive broadcasts सबसे बड़े दुःस्वप्नों में से एक बन गए, और wifi में यह समस्या और गंभीर थी
  • बाद में bridges और switches ने ARP forwarding scope घटाने के लिए special hacks जोड़ने शुरू किए; कुछ devices, खासकर wifi access points, fake ARP replies भी बनाने लगे, लेकिन यह सब मूलतः तकनीकी जुगाड़ ही था

विरासत से हुई मौत

  • समय के साथ Ethernet पर non-IP protocols लगभग गायब हो गए, और network एक ऐसे ढाँचे में जम गया जिसमें physical layer wires के ऊपर bus-जैसा layer 2, उन buses को जोड़ने वाले bridges, और उनके ऊपर layer 3 routers बैठे थे
  • manual IP configuration की थकान बढ़ने पर automatic configuration की माँग आई, लेकिन devices पहले से Ethernet addresses के साथ factory से निकलते थे और IPv4 32-bit addresses manufacturing stage पर स्थायी रूप से unique देने के लिए पर्याप्त नहीं थे
  • अगर IP addresses को बस क्रम से दे दिया जाए, तो हम फिर Ethernet जैसी non-hierarchical संरचना पर लौट जाते, इसलिए यह उचित समाधान नहीं था
  • इसलिए bootp और DHCP आए, और इन्हें भी ARP की तरह special-case handling वाले protocols बनना पड़ा
  • DHCP में IP address न रखने वाला node पहले transmission करता है, इसलिए उसे RFC में तय format वाला लगभग अर्थहीन IP header भरना पड़ता है, और DHCP server को kernel IP layer की बजाय raw socket से इसे सीधे बनाना पड़ता है
  • bootp और DHCP को अंततः Ethernet address जानना ही पड़ता है ताकि IP address दिया जा सके, इसलिए वे ARP के उल्टे रूप जैसा काम करते हैं
  • RARP वही काम अधिक सरलता से करता था, लेकिन यहाँ उसका लगभग उल्लेख नहीं किया गया है
  • नतीजतन Ethernet और IP एक-दूसरे में इतने गुँथ गए कि आज उन्हें लगभग अलग करना असंभव है
  • IP routing table ऊपर-ऊपर IP address से router बताने का नाटक करती है, लेकिन वास्तव में वह MAC address को अप्रत्यक्ष रूप से बताती है; ARP bridges के ऊपर से गुजरता है और DHCP IP packets जैसा दिखता है, जबकि असल में वह Ethernet protocol के अधिक क़रीब है
  • साथ ही bridging और routing दोनों और जटिल होते गए; bridging ज़्यादातर IEEE और hardware क्षेत्र में, और routing ज़्यादातर IETF और software क्षेत्र में बँटी रही, जैसे दोनों एक-दूसरे को नज़रअंदाज़ कर रहे हों
  • network operators speed requirements और DHCP server configuration से बचने जैसी प्राथमिकताओं के आधार पर bridging या routing चुनते थे; वे जहाँ तक संभव हो bridging ज़्यादा करते और ज़रूरत पड़ने पर ही routing इस्तेमाल करते
  • bridging की जटिलता अंततः layer 2 decision-making को ऊपरी layers तक खींचकर IP के ऊपर protocols से centrally managed करने वाले SDN तक पहुँची
  • SDN switches और bridges के अपने-अपने मनमाने व्यवहार से बेहतर था, लेकिन यह तर्क दिया गया कि जब बहुत बड़े network को software से संभालने वाला IP स्वयं पहले से software-defined network था, तो इसमें कुछ बुनियादी विडंबना है
  • शुरुआती दौर में IPv4 का hardware acceleration कठिन था और व्यवहार में पर्याप्त नहीं था; DHCP configuration भी बहुत झंझटभरी थी, इसलिए operators ने लगातार बड़े दायरे को bridge करना सीख लिया
  • आज के बड़े data centers को व्यवहार में SDN-आधारित विशाल virtual bus networks जैसा बताया गया है, जहाँ अक्सर packets को वास्तव में route तक नहीं किया जाता

अब ऊपर की कहानी थोड़ी देर के लिए भूल जाएँ

  • 1990 के शुरुआती दशक में जब IETF IPv6 की कल्पना कर रहा था, तब काफ़ी अराजकता शुरू हो चुकी थी, लेकिन फिर भी यह मानकर डिज़ाइन किया गया कि आने वाली आपदा से बचा जा सकता है
  • उस प्रक्रिया में एक अहम बदलाव यह था कि physical bus networks का उपयोग लगभग बंद हो चुका था
  • Ethernet अब वास्तविक bus नहीं रहा था, सिर्फ़ bus होने का नाटक करता था; speed बढ़ने के साथ CSMA/CD बनाए रखना संभव नहीं रहा, इसलिए यह फिर star topology पर लौट गया
  • हर station से central switch तक अलग cable ले जाने की संरचना सामान्य हो गई, और दीवारें, छतें तथा फ़र्श बड़े और महंगे Ethernet cables के गुच्छों से भर गए
  • यहाँ तक कि wifi भी, जो साझा wireless medium होने के कारण अंतिम bus जैसा दिखता है, व्यवहार में लगभग हमेशा infrastructure mode के ज़रिए एक बड़े star topology की नकल करता है
  • एक ही access point से जुड़े दो wifi stations भी सीधे बात नहीं करते; वे दूसरे node का MAC address डाले हुए packet access point को भेजते हैं और access point उसे फिर प्रसारित करता है
  • अगर node X, Internet node Z को, IP router Y के जरिए, wifi access point A के माध्यम से packet भेज रहा हो, तो Z IP destination है, Y Ethernet destination है, और A वास्तविक wireless transmission peer बन जाता है; इस तरह address layers जटिल रूप से एक-दूसरे पर चढ़ जाती हैं
  • इसी के लिए 802.11 वास्तविक Ethernet destination और intermediate Ethernet destination दोनों रखने वाला 3-address mode देता है
  • इसमें to-AP, from-AP bits भी होते हैं, जो station→AP और AP→station दिशा बताते हैं; और अगर दोनों bits एक साथ true हों, तो AP-to-AP relay behavior भी व्यक्त किया जा सकता है
  • यदि A एक repeater हो और उसे आगे base station B को भेजना हो, तो over-the-air actual sender/receiver और Ethernet source/destination सब अलग हो जाते हैं, इसलिए 4-address mode चाहिए
  • 802.11s mesh में तो 6-address mode तक है, और लेखक लिखता है कि उस बिंदु पर उसने समझना छोड़ दिया

वह दुनिया जहाँ IPv6 एक अच्छा डिज़ाइन था

  • IPv6 पर विचार करते समय IETF ने पहले से मौजूद अराजकता और आने वाली उससे भी बड़ी अराजकता को देखते हुए legacy को छोड़कर एक नई दुनिया की कल्पना की
  • उस दुनिया की धारणाएँ थीं: physical bus networks का हटना, layer 2 internetwork का हटना, broadcast का हटना, MAC addresses का हटना, ARP और DHCP का हटना, hardware-acceleratable simple IP header, address scarcity का अंत, और core को छोड़कर manual IP configuration का अंत
  • यदि layer 2 हमेशा point-to-point हो, तो broadcast भेजने के लिए कोई target ही नहीं बचेगा, इसलिए उसे multicast से बदला जा सकता है; और sender व receiver स्पष्ट होने से MAC addresses भी अनावश्यक हो जाते
  • MAC addresses के हटते ही IP और MAC के बीच mapping की ज़रूरत नहीं रहती, इसलिए ARP और DHCP भी गायब हो सकते थे; साथ ही इतना address space मिलता कि बड़े subnets के साथ routing फिर से व्यावहारिक हो जाती
  • उस दुनिया में wifi repeaters, wifi access points, Ethernet switches और SDN तक सब IPv6 routers की तरह काम करते, ऐसी कल्पना रखी गई
  • तब ARP storms, IGMP snooping bridges और bridging loops गायब हो जाते, और हर routing समस्या को traceroute से ट्रेस किया जा सकता था, ऐसी उम्मीद थी
  • हर Ethernet packet से source/destination MAC addresses के 12 bytes, और हर wifi packet से 18 bytes की address information हटाई जा सकती थी; इसलिए भले ही IPv6, IPv4 की तुलना में 24 bytes बड़े addresses उपयोग करता है, Ethernet header हटाने पर वास्तविक अतिरिक्त overhead केवल 12 bytes बचता है
  • इस तरह कभी Ethernet addresses को ही हटा देने की उम्मीद ने IPv6 address length के अत्यधिक बड़े चयन को उचित ठहराने में मदद की, ऐसा कहा गया है
  • लेकिन यह सुंदर डिज़ाइन वास्तविक दुनिया में साकार नहीं हुआ

सपने के लिए शोकगीत

  • "layers केवल जुड़ती हैं, हटती नहीं" — लेखक के एक सहकर्मी की यह बात पूरे निष्कर्ष के रूप में सामने आती है
  • IPv6 के लाभ तभी सही बैठते थे जब पुरानी legacy को छोड़कर दोबारा शुरुआत की जा सके, लेकिन वास्तविकता में यह लगभग असंभव निकला
  • भले ही IPv6 adoption 99% तक पहुँच जाए, जब तक IPv4 पूरी तरह गायब नहीं होता तब तक Ethernet addresses और wifi addresses भी नहीं जाएँगे; और जब तक IEEE 802.3 और 802.11 framing standards बने रहेंगे, तब तक bytes की वह बचत भी नहीं मिलेगी
  • इसलिए IPv6 को अंततः ARP से भी अधिक जटिल neighbor discovery की ज़रूरत पड़ी, और भले bus networks गायब हो गए हों, ARP-जैसे व्यवहार के लिए broadcast-जैसी simulation अब भी करनी पड़ती है
  • घरों में पुराने IPv4 smart bulbs चलाने के लिए local DHCP server अब भी चलाना पड़ता है, और उन bulbs को Internet तक पहुँचाने के लिए NAT भी अभी चाहिए
  • इससे भी बुरा, लेखक के अनुसार IPv6 टीम mobile IP की समस्या हल किए बिना आगे बढ़ गई, और उसके परिणामस्वरूप भयानक layer 2 bridging अब भी ज़रूरी रही
  • लेखक के हिसाब से उस समय योजना शायद यह थी कि पहले कुछ वर्षों में IPv6 deploy होगा, फिर IPv4 और MAC addresses हटने के बाद mobile IP को आसानी से हल किया जाएगा
  • उस समय यह भी माना जाता था कि चलते-फिरते computers का use case लगभग न के बराबर है; ज़्यादा से ज़्यादा Ethernet ports के बीच जाते हुए ftp session जारी रखने जैसी अजीब कल्पनाएँ की जा सकती थीं

mobile IP नाम का killer app

  • बाद के इतिहास में portable computers, यानी phones, को कई wireless access points के बीच ले जाना एक रोज़मर्रा का उपयोग बन गया
  • LTE में यह mobility अक्सर काम करती है और wifi में कभी-कभी, लेकिन लेखक के अनुसार इसका राज Internet routing नहीं बल्कि layer 2 bridging है
  • Internet routing mobility को बिल्कुल handle नहीं कर पाती; IP network में चलते हुए IP address बदलते ही खुले हुए सारे connections टूट जाते हैं
  • enterprise wifi पूरे LAN को layer 2 पर bridge करके central DHCP server से यह सुनिश्चित करता है कि device किसी भी access point से जुड़े, उसे वही IP address मिले; bridge reconfiguration के कुछ सेकंड के भ्रम के बावजूद connection बना रहता है
  • कई extenders या repeaters वाले home wifi भी यही तरीका अपनाते हैं
  • इसके विपरीत, सड़क पर चलते हुए दुकानों द्वारा दिए गए अलग-अलग wifi networks के बीच जाने पर हर बार नया IP address मिलता है और हर बार सभी connections टूट जाते हैं
  • LTE इससे भी आगे जाकर कई miles दूर तक अलग-अलग base stations के बीच घूमते हुए भी वही IP address बनाए रखता है; और mobile networks आम तौर पर IPv6 addresses का उपयोग करते हैं
  • इसका तरीका traffic को एक central point तक tunnel करना और फिर कई firewalls के साथ उसे एक विशाल virtual layer 2 LAN की तरह bridge करना है; इसकी कीमत है बहुत भारी जटिलता और शर्मनाक स्तर का extra latency
  • carriers इसे सुधारना चाहते हैं, लेकिन लेखक के अनुसार यह लगभग असंभव है

mobile IP को वास्तव में काम कराने का तरीका 1

  • mobile IP ठीक से क्यों नहीं चलता, इसका उत्तर लेखक इस निष्कर्ष तक ले जाता है कि session identification के लिए इस्तेमाल होने वाली प्रसिद्ध 4-tuple परिभाषा ही ग़लत है
  • TCP और UDP sessions को (source ip, source port, destination ip, destination port) से पहचाना जाता है; यह संरचना layer 3 और layer 4 को आपस में बाँध देती है और IP address बदलने पर टूट जाती है
  • अगर session identification केवल layer 4 data से होती, तो mobile IP बिल्कुल सही काम करती — ऐसा तर्क दिया गया है
  • उदाहरण के लिए, जब X:1111, Y:80 से बात कर रहा हो और X का address बदलकर Q हो जाए, तो packet (Q,1111,Y,80) बनता है; Y इसे पुराने session का हिस्सा नहीं पहचानता और drop कर देता है, और Y का (Y,80,X,1111) reply अब X तक पहुँच ही नहीं पाता
  • विकल्प के तौर पर ports को मौजूदा 16-bit की जगह 128 या 256-bit के unique hash values जितना बड़ा करने और sockets को IP address से स्वतंत्र tags से पहचानने की कल्पना दी गई है
  • इस स्थिति में packets layer 3 पर अब भी (X,Y) address information लेकर route होंगे, लेकिन kernel receive करते समय socket identification के लिए layer 3 info का उपयोग नहीं करेगा, सिर्फ़ uuid का करेगा
  • destination port 80 की ज़रूरत सिर्फ़ नया session शुरू करते समय वांछित service चुनने के लिए होगी; उसके बाद उसे ignore या omit किया जा सकता है
  • Y का kernel cache करेगा कि (uuid) session packets हाल में X से आए थे; X के Q पर चले जाने के बाद यदि वही (uuid,80) tag फिर आता है, तो kernel उसे उसी session से match करके reply destination को X से Q में अपडेट कर सकता है
  • इससे connection बना रहेगा, लेकिन spoofing के ज़रिए connection hijack रोकने के लिए अतिरिक्त सावधानी की आवश्यकता होगी
  • लेकिन UDP और TCP इस तरह काम नहीं करते, और अब इसे बदलना लेखक के अनुसार वैसा प्रोजेक्ट है जो IPv4 को IPv6 में बदलने जितना आसान लगा था, लेकिन दशकों बाद भी आधे से कम ही पूरा हुआ है

QUIC और bypass की संभावना

  • सकारात्मक पक्ष यह है कि एक और layer violation के ज़रिए indirect समाधान संभव बताया गया है
  • पुराने TCP को छोड़कर UDP के ऊपर QUIC इस्तेमाल किया जाए, तो UDP 4-tuple को connection identifier के रूप में न इस्तेमाल करने वाली संरचना संभव हो जाती है
  • अगर UDP port किसी विशेष mobility layer का port हो, तो उसके भीतर की सामग्री को फिर खोलकर उपयुक्त uuid tag वाले internal packets के रूप में समझा जा सकता है और उन्हें सही session तथा socket से match किया जा सकता है
  • experimental QUIC protocol कम-से-कम सिद्धांत में ऐसी संरचना के अनुकूल packet format पहले से रखता है, ऐसा कहा गया है
  • QUIC के stateless packet encryption और authentication में वैसे भी unique session identifiers या keys की ज़रूरत होती है, इसलिए अपेक्षाकृत कम काम से transparent roaming support संभव हो सकता है — ऐसी आशा जताई गई है
  • अगर ऐसा हो जाए, तो बस Internet से बाकी UDP और TCP भी हटा देने होंगे, और फिर शायद इस बार वास्तव में layer 2 bridging की ज़रूरत नहीं बचेगी, साथ ही broadcast, MAC addresses, SDN और DHCP भी हटाए जा सकेंगे
  • अंत में निष्कर्ष Internet की elegance की बहाली पर समाप्त होता है

पूरक संशोधन

  • 2017-08-16 संशोधन

    • mobile IP पर ऊपर की गई कल्पना IPv6 तक सीमित नहीं है
    • इसे IPv4 और NAT environments में, यहाँ तक कि कई NATs के पार roaming में भी काम करने योग्य बताकर संशोधित किया गया

  • 2017-08-15 संशोधन

    • connection hijacking रोकने के उपाय के रूप में TCP startup के समय SYN-ACK-SYNACK जैसी exchange को सबसे सरल उदाहरण बताया गया है
    • यदि Y नए host Q से आए पहले packet पर तुरंत भरोसा कर ले, तो Internet में कहीं से भी कोई attacker X→Y connection हाईजैक कर सकता है
    • लेकिन अगर Y एक cookie भेजे और Q उसे लेकर process करके वापस Y को लौटाए, तो कम-से-कम साधारण बाहरी attacker की बजाय man-in-the-middle स्तर का attacker चाहिए होगा
    • QUIC जैसे encrypted protocols में यह handshake session key से सुरक्षित भी किया जा सकता है

  • 2017-10-24 संशोधन

    • QUIC के अलावा roaming support वाले TCP replacement protocols के और भी उम्मीदवार हैं, और MinimaLT का उदाहरण दिया गया है
    • लिखा गया है कि MinimaLT roaming समस्या को सुंदर ढंग से हल करने वाला पहला protocol था जिसके बारे में लेखक ने सुना, और भविष्य में अपनाया जाने वाला समाधान भी शायद इसी संरचना का अनुसरण करे

  • 2020-07-09 संशोधन

    • IPv4/IPv6 migration और interoperability पर अतिरिक्त विचार किसी दूसरे लेख में पोस्ट किए जाने का केवल उल्लेख है; यहाँ मुख्य लेख में कोई अतिरिक्त व्याख्या नहीं है

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.