در نوشته ها و گفته های متعدد در رابطه با IPv6 با این عبارت روبه رو می شویم که:
IPv6 عملکرد بهتری نسبت به IPv4 دارد.
و گاهی در پی این عبارت دلایلی نیز آورده می شود. اما چه میزان این مطلب و دلایلی که در پی آن به عنوان مواردی برای بهبود عملکرد IPv6 مطرح می شوند، صحت دارند؟ بیان بسیاری از این دلایل شاید تنها در وجههی عمومی و همراه ساختن عموم جامعه در حرکت به سمت استفاده از IPv6 قانعکننده و مقبول باشند اما از لحاظ فنی این انتظار وجود دارد که یک کارشناس حوزهی اینترنت، توانایی استدلال در رد یا قبول هر یک از دلایلی که در پی این عبارت مطرح می شوند را داشته باشد. در این مقاله قصد داریم تا نگاهی فنی تر به این دلایل داشته باشیم.
***
در IPv6 انجام تغییراتی در ساختار و قالب این پروتکل سبب ایجاد بهبود کارایی آن در برخی موارد گشته که عبارتند از:
1- فضای آدرس دهی بسیار بزرگتر
اولین مزیتی که برای IPv6 بیان می شود آن است که IPv6 فضای آدرس دهی بزرگتری نسبت به IPv4 داشته و به همین دلیل می تواند تعداد آدرس های بیشتری را فراهم آورد. بله این عبارت درست است! IPv6 به دلیل 128 بیتی بودن قادر است تقریبا 3.4*10^38 آدرس ممکن را فراهم کند که با گسترش شبکه ها و افزایش دستگاه هایی که توانایی اتصال به اینترنت را دارند، این مقدار آدرس IP تا مدت های زیادی جوابگوی نیازها خواهد بود. اما این موضوع چه ارتباطی با بهبود عملکرد IPv6 دارد؟
تصور کنید آنقدر آدرس IP وجود دارد که هر دستگاه می تواند Public IP (آدرس عمومی اینترنی) متعلق به خود را داشته باشد. دقت کنید که گفته شد آدرس Public IP. بله دقیقا منظور آدرس های IP ای هستند که در دنیای اینترنت قابل مسیریابی می باشند. به نظر شما زمانی که هر دستگاه بتواند یک آدرس Public IP مخصوص به خود داشته باشد و خود به صورت مستقیم به اینترنت متصل گردد، چه مزیتی وجود خواهد داشت؟
برای رسیدن به جواب این سوال، به چندین سال قبل، زمانی که برای اولین بار احساس شد که آدرس های عمومیِ IPv4 رو به اتمام هستند، باز می گردیم. در آن زمان اولین راهکاری که برای نجات IPv4 از این اوضاع مطرح شد، راهکاری به اسم Network Address Translation یا همان NAT بود.
عملی که این راهکار انجام می داد آن بود که دستگاههایی که در داخل یک ساختار (مثلا دستگاه های داخل یک سازمان یا دستگاه های داخل خانه و یا …) قرار داشتند، برای آن که بتوانند با هم ارتباط برقرار نمایند، از آدرس هایی استفاده می کردند معروف به Private IPv4 (RFC1918) که این آدرس ها در اینترنت قابل مسیریابی نبودند و اگر قرار بود این دستگاه ها به اینترنت متصل شوند و با سایر دستگاه ها در دنیای اینترنت ارتباط داشته باشند، Private IP آن ها توسط gateway آن ساختار (مثلا مودم یا روتر) به یک Public IP ترجمه می شد. به این ترتیب دیگر نیازی نبود که همهی دستگاه های درون یک ساختار یک IP آدرس Public مجزا و مخصوص به خود داشته باشند، بلکه کافی بود به کل ساختاری که دستگاه ها در آن قرار داشتند تنها یک آدرس عمومی IPv4 تعلق گیرد و هر دستگاهی که قصد برقراری ارتباط با اینترنت را داشت، آدرس Private آن به آدرس Public اختصاص یافته به ساختار ترجمه می گشت.
این ترجمه ی آدرس، خواه یا ناخواه باعث ایجاد پیچیدگیهای سخت افزاری در دستگاه gateway و همین طور صرف زمانی (هرچند اندک) برای ترجمه ی آدرس ها از Private به Public و برعکس می شد. از سوی دیگر پیکربندی دستگاه gateway برای پشتیبانی از NAT در برخی مواقع خیلی سخت و باعث تاثیر سو بر یکسری عملکردهای دیگر می گشت.
حال بیایید به سراغ سوالمان برویم: اگر هر دستگاهی بتواند برای خود یک Public IP مستقل خود داشته باشد چه مزیتی خواهد داشت؟ بر اساس آن چه که بالا گفته شد مفهوم NAT در چنین حالتی به طور کل از بین می رود و هنگامی که NAT نباشد، پیچیدگی سخت افزاری و زمان اضافی برای ترجمهی آدرس پکت های ورودی و خروجی به دستگاه gateway کاهش پیدا می کند و از سوی دیگر پیکربندی ساختار شبکه هم به طرز قابل ملاحظه ای ساده تر می گردد!
2- ارتباطات end-to-end
زمانی که هر دستگاهی آدرس Public IP مختص خود را داشته باشد و نیازی به NAT نباشد، به این معنی است که ارتباط دستگاه ها کاملا به صورت end-to-end خواهد بود در نتیجه در ساختارهای IPv6، اپلیکیشن های peer-to-peer ای مثل VoIP عملکرد کارآمدتر و موثرتری خواهند داشت.
3- آدرس دهی آسان تر دستگاه ها
یکی از دغدغه ها در ساختارهای IPv4، روش های IP دهی به دستگاه ها است. در چنین ساختارهایی اطلاعاتی مثل آدرس IP، Gateway، DNS Server و … برای یک دستگاه یا باید به صورت دستی برای آن دستگاه تنظیم شوند و یا دستگاه ها این اطلاعات را از طریق یک DHCP Server به دست آورند.
در ساختارهای IPv6 این مکانیزم ساده تر شده است. دستگاه ها برای به دست آوردن اطلاعات شبکه هم می توانند از یک DHCP سرور (DHCPv6) استفاده نمایند که به این روش اصطلاحا Stateful Address Auto Configuration گفته می شود و یا این که در روشی جذابتر، بطور خودکار صاحبِ یک Global IPv6 Address شوند که به این روش اصطلاحا Stateless Address Auto Configuration گفته می شود. در این روش یک Host از طریق یک یا چند Link Prefix ای که از طریق یک پیام RA (Router Advertisement) به دست آورده، و اضافهکردن آن به ابتدای Interface ID که برای خود محاسبه کرده، صاحب یک Global IPv6 Address میشود. پس در ساختارهای IPv6، حتی اگر هیچ تنظیم خاصی هم صورت نگیرد و دستگاه فقط IPv6 Enabled باشد کافی است تا یک آدرس IP عمومیِ مختص به خود را داشته باشد.
همین امر سبب آسان تر شدن مدیریت آدرس های IPv6 می شود. تصور کنید در یک ساختار IPv4 قرار بر تغییر طرح آدرس دهی شبکه باشد. در چنین شرایطی شما به عنوان مدیر شبکه باید تک تک دستگاه ها را دوباره آدرس دهی نمایید اما در IPv6 با همین ویژگیِ آدرسدهی خودکار، سربارِ کاریِ شما نیز به عنوان یک مدیر به مراتب کاهش چشمگیری پیدا کرده و ساده تر می شود.
4- افزایش سرعت در پردازش پکت ها
قبل از پرداختن به این مورد بهتر است نگاهی به هدر IPv4 و هدر IPv6 بیاندازیم:
دو موضوع در IPv4، پردازش پکت های مربوط به آن را زمانبر میکند. اول آن که هر روتری که یک پکت IPv4 دریافت کند باید برای بررسی عدم وجود خطا و مشکل در پکتی که دریافت کرده، مجددا Checksum را برای آن پکت محاسبه کرده و مقدار به دست آمده را با مقدار فیلد Checksum پکت دریافتی مقایسه نماید. دوم این که اگر قرار بر انجام یکسری عملیات های اختیاری برای پکت IPv4 باشد (مثلا Source Routing)، این عملیات ها توسط مقداری که در فیلد Option در هدر پکت IPv4 قرار می گیرند، مشخص می شوند و هر روتری که یک پکت IPv4 دریافت نماید باید فیلد option در هدر IP آن پکت را نیز بررسی کند.
اگر این موضوع را در نظر بگیریم که پروتکلهای لایههای بالاتر دارای مکانیزمهای تشخیص و تصحیح خطا هستند، آیا نمیتوان Checksum را از هدر IP حذف نمود و به این ترتیب زمانی برای محاسبه ی checksum صرف نگردد؟
یا به عنوان مثال، اگر برای پکتی قرار نباشد هیچ عملیات خاصی صورت گیرد و فیلد option هم خالی باشد، نمیتوان کاری کرد که روتر مجبور به انجام این بررسی اضافی نباشد؟ و یا فقط برای پکتهایی این بررسی را انجام دهد که در فیلد option آن ها مقداری وجود داشته باشد؟
افرادی که در حال توسعه ی IPv6 بودند نیز دقیقا با در نظر گرفتن این سوال ها به یک نتیجه ی مهم دست یافتند: آن ها نه تنها فیلدهای checksum و option، بلکه تمام فیلدهای اضافی را که معمولاً در شرایط عادی اصلا استفاده نشده (که صرفاً بدلیل وجود در IPv4 Header مورد بررسی قرار میگرفتند) را از هدر IPv6 حذف کردند و به این ترتیب به دو طریق سبب افزایش سرعت پردازش و کارایی هدر پکت IPv6 شدند:
- اول آن که یک پکت IPv6 فقط اطلاعات مورد نیاز را حمل می کند و هیچ فیلد بلااستفاده ای در هدر آن وجود ندارد.
- دوم آن که دیگر نیازی به پردازش اضافی برای بررسی عملکردهای اختیاری نیست، چرا که اطلاعات مربوط به این عملکردها توسط هدرهای جداگانه ای حمل می شوند که اصطلاحا Extension Header نامیده می شوند.
همین دو عامل سبب می شوند که روترهایی که در میانهی راه رسیدن یک بسته از یک مبدا به یک مقصد قرار دارند، دیگر نیازی به صرف زمان برای تجزیه و تحلیل هدر پکت IPv6 و انجام اعمالی مثل تکه تکه کردن پکت (Fragmentation) و سرهم کردن مجدد آنها (reassembly) نداشته باشند و به این ترتیب سربار پردازش روترها و پیچیدگی سخت افزاری کاهش پیدا کرده و پردازش پکت ها سریعتر انجام شود.
5- پشتیبانی ذاتی از Multicasting و مدیریت کارآمدتر جریان ترافیک در ساختار
یکی از مشکلات IPv4 ضعف و محدودیت آن در اعمال Multicasting است. در ساختارهای IPv4 این عمل تنها میتواند به زیرشبکه ها خلاصه شود و اکثر روترهای اینترنتی نمی توانند از IPv4 Multicasting پشتیبانی کنند. در IPv6 این مشکل دیگر وجود ندارد و علت آن نیز پشتیبانی ذاتی IPv6 از Multicasting می باشد. تمام دستگاه هایی که IPv6 بر روی آن ها فعال شود در کم ترین حالت، به صورت خودکار عضو یک گروه Multicast یکسان خواهند شد. همینطور برخلاف IPv4 که برای عمل Multicasting یک رنج محدود IP در نظر گرفته شده بود، در IPv6 این بازه به مراتب خیلی بزرگتر شده و دیگر محدودیت های تعداد IP های Multicast نیز وجود ندارد.
اما IPv6 مکانیزم جالبتری را نیز برای مدیریت بهتر و کارآمدتر جریان ترافیک در یک ساختار ارایه می دهد، یعنی آدرس های Anycast.
با استفاده از آدرس های Anycast می توان به مجموعه ای از nodeها، آدرس یکسانی اختصاص داد. به عنوان مثال تصور کنید در ساختاری چند سرور وجود دارد که سرویس یکسانی ارایه میدهند، مثلاً چندین DNS Server در شبکهی وسیع یک سرویسدهندهی اینترنت. همه ی آن ها می توانند یک آدرس Anycast یکسان داشته باشند، و روتر زمانی که قرار باشد ترافیک سرویس مربوطه را به یکی از این سرورها ارسال کند، نزدیکترین سرور را به صورت خودکار انتخاب می نماید؛ اگر این سرور نزدیکتر بنا به هر دلیلی fail شود، روتر بلافاصله سرور نزدیکتر بعدی را جایگزین آن خواهد کرد.
موارد بالا به صورت خلاصه بر تغییراتی که سبب بهبود عملکرد IPv6 می شدند اشاره داشتند اما در این میان اشتباهات و تصورات نادرستی نیز در رابطه با IPv6 و کاربردهای آن وجود دارد:
1- IPv6 از IPv4 امن تر است:
این گفته معمولاً بخاطر بحث پشتیبانی ذاتی IPv6 از IPSec بیان میشود، اما چنین نتیجهگیری چندان هم درست نیست چرا که هم در IPv4 و هم در IPv6، زمانی این امنیت وجود دارد که شما IPSec را پیاده سازی نمایید. مزیت و برتری IPv6 نسبت به IPv4 در بحث IPSec آن است که، در IPv6 اطلاعات مربوط به IPSec از طریق Extension Header ها منتقل می شوند، و علیالخصوص دیگر مشکلی برای انتقال ترافیک Multicast از طریق یک IPv6 IPSec VTI وجود ندارد. در IPv4 انتقال ترافیک Multicast از طریق یک IPv4 IPsec VTI امکان پذیر نیست و برای این منظور باید از تانل هایی چون GRE استفاده شود. این بیشتر بمعنی پیچیدگی کمتر هست، تا امنیت بیشتر!
چه بسا IPv6 به خاطر داشتن مکانیزم های Plug-and-Play، عدم فیلترینگ ICMPv6 در خیلی از موارد و … مشکلات امنیتی بیش تری نسبت به IPv4 بهمراه بیاورد.
2- با از بین رفتن NAT در IPv6، امنیت کاهش می یابد:
در حقیقت هیچ گاه NAT به معنای مکانیزمی برای ایجاد امنیت نبوده و همانطور که در ابتدای این متن نیز توضیح داده شد، هدف از NAT تنها کاهش نیاز به آدرس های عمومی IPv4 بوده است و این امر که با NAT آدرس حقیقی دستگاه مخفی می ماند، برداشت درستی نیست. از سوی دیگر با توجه به وسعت آدرسهای IPv6، اسکنکردن این آدرسها به منظور یافتن هاستهای آسیب پذیر امری بی فایده تلقی می شود. پس بطور کلی، وجود یا حذف NAT هیچ تاثیری بر امنیت یا عدم امنیت در IPv6 نخواهد داشت.
3- IPv6 از QoS پشتیبانی بهتری به عمل می آورد:
یکی از عواملی که منجر به این برداشت اشتباه می گردد درک اشتباه نحوهی عملکرد فیلدی با نام Flow Label در هدر IPv6 می باشد. با Flow Label می توان پکت های متعلق به یک جریان یکسان (یعنی ترافیکی که مبدا و مقصد یکسانی داره) را برچسب زد و مشخص نمود که این پکت ها همیشه از یک مسیر یکسان به سمت مقصد مورد نظر ارسال شوند. شاید این فیلد به نوعی به جریان ارسال ترافیک بر روی لینکهایی با پهنایباند کم کمک کند اما در لینک هایی با پهنایباند بالا نیز همچنان مجبور خواهید بود که اعمال مربوط به DiffServ را از طریق فیلد DSCP که در هدر IPv6 با نام Traffic Class نامیده می شود، انجام دهید. بنابراین QoS در IPv6 و IPv4 فرق چندانی با یکدیگر نخواهند داشت.
4- IPv6 باعث کاهش سایز Routing Table خواهد شد:
گاها اینگونه مطرح می شود که با آدرس دهی سلسله مراتبی و تجمیع آدرس های IPv6 می توان سایز جداول Route را کاهش داد. این مساله در IPv4 نیز به همین شکل صادق است و تفاوت چندانی بین IPv4 و IPv6 در این مبحث وجود ندارد. از سوی دیگر بیان می شود که مکانیزم های Multihoming در IPv6 چون SHIM، SCTP و … می توانند به امر کاهش سایز جدوال Route کمک کنند اما حقیقت آن است که IETF با وجود چندین سال تلاش هنوز نتوانسته است این راهکارها را عملی نماید و هنوز هر فردی می تواند آدرس Global خود را داشته و بر حجم جداول Route بیافزاید.
5- IPv6 سبب کاهش مشکلات BGP می گردد:
نه تنها IPv6 مشکلات BGP را کم نمی کند بلکه ممکن است بر این مشکلات نیز بیافزاید. همانطور که در بالا نیز ذکر گردید در دنیای IPv6 هرکسی می تواند آدرس global خود را داشته باشند، پس نه تنها سایز جداول Route اینترنتی افزایش می یابد بلکه IPv6 BGP Routing Tableها، فضای بیشتر و متعاقبا پهنای باند بیشتری نسبت به IPv4 BGP Routing Table ها استفاده می کنند. البته با توجه به اینکه روز به روز تجهیزات اینترنتی قویتر شده و media های جدید پهنای باند بیشتری ارائه میکنند، نگرانی مصرف پهنایباند بیشتر بخاطر سایز بیشتر IPv6 Routing Table قابل چشمپوشی خواهد بود. اما مشکل دیگری که بواسطهی افزایش تعداد Route ها در دنیای اینترنت و BGP بوجود میآید، بحث Flapping روتها خواهد بود که باعث ناپایداری اینترنت خواهد شد. البته به مرور زمان مکانیزمهاو سیاستهای بهتری جهت افزایش Stability جداول روتینگ بوجود میآیند کمااینکه مثلاً در حال حاضر بحث Route Flap Damping وجود دارد (RFC7196 و RIPE-580)
آن چه در این مقاله بررسی گردید، عملکرد IPv6 ای است که هنوز در حال توسعه و تلاش برای بهبود و گسترش می باشد. چه بسا در آینده برای تمام معایب ذکر شده در بالا راهکاری عملی یافت شود و چه بسا خیلی از مواردی که به عنوان مزیت برای این پروتکل مطرح گردید هیچ گاه در دنیای واقعی عملی نشوند. در هر حال حرکت به سوی IPv6 آغاز شده و با تمام مزایا و معایب، دیر یا زود همه درگیر این پروتکل خواهند شد.
سلام
اول ممنون از مطالب کاربردی تون
در مورد بخش دوم تصورات نادرست یعنی تاثیر NAT در امنیت سوالی برام بوجود اومده
اونم اینکه خب در این حالت مهاجم نمیتونه مستقیما با کاربر در ارتباط باشه و در نتیجه امکان نفوذ به سیستم رو به حداقل میرسونه البته در NAT متود هایی مثل PAT و Full Cone NAT وجود داره ولی در حالت پیش فرض NAT خب بنظرم باعث ایجاد امنیت در سمت داخلی میشود تا حدودی
ممنون میشم اگر اشتباه برداشت کردم توضیح دهید یا لینکی برای توضیح مطلب قرار دهید
ممنون
سلام. ممنونم.
بحث جالبی رو مطرح کردین.
قضیه اینه که NAT همراه خودش یکسری جوانب داره که میشه گفت نمود امنیتی دارن. اما اصل NAT، “بنظر بنده” نباید بعنوان یک ویژگی و افزوده ی امنیتی شناخته بشه.
فکر کنم بهتر باشه بگیم NAT ابزاری در طراحی هست که در معماری امنیتی ازش در موقع نیاز میشه استفاده کرد (مثلاً برقراری ارتباط با یک شبکه ی دیگه) اما به صرف خود جای firewall رو نمی گیره و یک ویژگی امنیتی نیست.
شاید خوب باشه رفتار انواع NAT رو از بالا و بطور کلی بررسی کنیم:
در کنار مواردی که عرض کردم، NAT گاهی مشکلات/محدودیت/پیچیدگی رو هم بهمراه خودش میاره، مخصوصاً در شرایطی که end-to-end connectivity مهم هست (مثلاً در IPSec که authentication و encryption به ثبات IP address ها در IP header وابستگی دارن؛ البته که میشه یجورایی این مشکلات رو دور زد اما همین دور زدن خودش یک پیچیدگی اضافی هست)
پیشنهاد میکنم دو بخش Security Considerations از RFCهای 2993 و 2663 رو مطالعه کنین:
بجز توضیحاتی که بنده عرض کردم، در مطالب زیر هم توضیحات خیلی خوبی ارائه شده:
فراموش نکنیم: NAT برای حل موقتی مشکل کمبود IPv4 بوجود اومد! (که امروزه گاهی به عنوان یک آپشن امنیتی دیده میشه). اگر تصور کنیم NAT برای ما امنیت بوجود آورده ممکنه از سایر بحث های امنیتی دور بشیم.
و لطفاً گفته های بنده مبنی بر این نباشه که نباید از NAT استفاده کرد؛ عرضِ من همونیه که اول گفتم: “NAT ابزاری در طراحی هست که در معماری امنیتی ازش در موقع نیاز میشه استفاده کرد (مثلاً برقراری ارتباط با یک شبکه ی دیگه) اما به صرف خود جای firewall رو نمی گیره و یک ویژگی امنیتی نیست.”
موفق باشید.
سلام بسیار عالی و کاربردی بود
سلام. خیلی ممنون از لطف شما.
عملکرد IPv6 نسبت به IPv4 در حال حاضر همیشه بهتر نیست. شاید مزایا یا قابلیت متفاوتی داشته باشه ولی نباید اونها رو با عملکرد بهتر اشتباه گرفت. پیشنهاد میکنم ارایه Vaibhav Bajpa در نشست IETF99 که پنج شنبه گذشته در پراگ برگزار شد رو ببینید. در تحقیقی که در یک بازه سه ساله در مورد عملکرد IPv6 با محتوای یوتیوب انجام دادند مشخص شد که IPv4 عملکرد بهتری داشته:
However, even though clients prefer streaming videos over IPv6, we observe
worse performance over IPv6 than over IPv4. We witness consistently higher TCP
connection establishment times and startup delays (∼100 ms or more) over IPv6.
We also observe consistently lower achieved throughput both for audio and
video over IPv6. We observe less than 1% stall rates over both address
families.
موفق باشید.
سلام. خیلی ممنون از اینکه سر زدید
بنده هم کاملاً با صحبت شما موافقم و در این مطلب هم سعی شد به این اشاره بشه که IPv6 چه مزایایی همراه خودش داره، و مهم تر اینکه چه تصورات غلطی دربارهاش وجود داره که باید ازشون پرهیز کرد.
بنظر بنده، اینکه بگیم IPv4 یا IPv6 عملکرد بهتری نسبت به هم دارند برداشت برداشت کاملی نیست. منظورم صرف پروتکل هست.
اما مستقلاً در رابطه با IPv6، من فکر میکنم علت اینکه گاهی حس میشه IPv4 نسبت به دیگری performance بهتری داره عموماً بخاطر اینه که هنوز IPv6 از لحاظ Adoption بجایی که باید تا امروز میرسید، هنوز نرسیده و متاسفانه خیلی اوقات ترافیک درگیر sub-optimal routing میشه. ولی خب ما در IETF در تمام Area ها تعهدنامه ای امضا کردیم که تمام پروتکل ها باید با اولیت برای IPv6 طراحی بشن. حتی در IETF97، یک اظهاریه توسط IAB منتشر شد که استانداردهای شبکه باید کاملاً از IPv6 پشتیبانی کنن و در پروتکل های جدید یا افزونههای جدید بر پروتکلهای قبلی، دیگه IPv4-compatibility بعنوان یک requirement نباشه. حتی یک working group ایجاد شده تحت نام Sunsetting IPv4. امیدوارم این تلاش کمک کنه که IPv6 به اونجایی که لازمه برسه.
تحقیقی که اشاره فرمودین قرار هست در نشست مربوط به IRTF (داخل IETF99 پراگ) 20 جولای در جلسه گروه maprg ارائه بشه. درواقع هنوز برگزار نشده اما معمولاً توی IETF بعضیا سریع هستن (که خیلی هم خوب هست) و از قبل اسلایدها رو قرار میدن تا افراد بتونن برنامه ریزی کنن و وقت بگذارن تا جلسات مفید باشه و بتونن بحث کنن.
بنده از 4 IETF قبلی همه رو شرکت کردم ولی خب بر حسب جهتگیری کارم، بیشتر در Routing Area (معمولاً wgهای i2rs، idr، mpls، rtgwg و spring) فعال هستم. اما اگر خودتون در IETF99 شرکت نمیکنین و فکر میکنین این ارائه ممکنه مورد علاقتون باشه شاید بتونم در اون جلسه برم و خروجیاش رو به اشتراک بگذارم؛ البته از چند IETF قبل همه جلسات record میشن و در YouTube قرار میگیرن. بجز این خودتون هم میتونین بصورت remote و رایگان در جلسات شرکت کنین.
از IETF97 سئول، بنده معمولاً در کانال تلگرام بلاگ و اینستاگرام مطالبی رو از جلسات به اشتراک میگذارم که اگر علاقه داشتید خوشحال میشم دنبال کنین.
خیلی ممنون
سلام
لطفا یک تعریف واضح از ارتباط end to end بنویسید
ممنونم