**کشف بیشینه واحد انتقال مسیر** (به انگلیسی: **PMTUD**) یک روش استاندارد شده در شبکه‌های کامپیوتری برای تعیین اندازهٔ بیشینه واحد انتقال (ام‌تی‌یو) در مسیر شبکه بین دو میزبان پروتکل اینترنت (IP)، معمولاً با هدف جلوگیری از چندپارگی IP است. *کشف* *بیشینهٔ واحد انتقال مسیر* در ابتدا برای روترها در نسخهٔ چهار پروتکل اینترنت (IPv4) در نظر گرفته شده بود. با این حال همهٔ سیستم عامل‌های مدرن از آن در نقاط انتهایی استفاده می‌کنند. در IPv6 این عملکرد صریحاً به نقاط انتهایی یک جلسهٔ انتقال محول شد.

PMTUD در RFC 1191 برای IPv4، و در RFC 8201 برای IPv6 استاندارد شده‌است (که RFC 1981، استاندارد قبلیِ IPv6 PMTUD، را منسوخ کرد). RFC 4821 تعمیمی را برای تکنیک‌ها توصیف می‌کند که بدون پشتیبانی شدن از طرف پروتکل کنترل پیام‌های اینترنتی کار می‌کند. RFC 8899 با معرفی راهنماهایی برای استفاده از PMTUD در لایهٔ بسته‌بندی با UDP و SCTP، نسخهٔ RFC 4821 را به روز کرد.

پیاده‌سازی
----------

برای بسته‌های IPv4، شیوهٔ *کشف بیشینهٔ واحد انتقال مسیر* با تنظیم *بیت پرچم DF (قطعه قطعه نکن)* در هدرهای IP بسته‌های خروجی است. سپس هر دستگاهی در طول مسیر که ام‌تی‌یو ی آن کوچکتر از بسته باشد، آن را رها کرده و یک پیام پروتکل کنترل پیام‌های اینترنتی (ICMP) *نیاز به قطعه بندی* (نوع ۳، کد ۴) حاوی *ام‌تی‌یو* خود را ارسال می‌کند، که به میزبان منبع اجازه می‌دهد تا مقدار *ام‌تی‌یو مسیر* خود را به درخور آن کاهش دهد. این روند تا زمانی تکرار می‌شود که ام‌تی‌یو به اندازه کافی کوچک باشد تا بتوان کل مسیر را بدون قطعه قطعه شدن طی کرد.

روترهای IPv6 از قطعه قطعه کردن پشتیبانی نمی‌کنند و در نتیجه از گزینه *قطعه قطعه نکن* (DF) *پشتیبانی نمی‌کنند. برای* IPv6، کشف ام‌تی‌یو مسیر کار را با در نظر گرفتن ام‌تی‌یو مسیر مانند ام‌تی‌یو در رابط لایه پیوند (جایی که ترافیک آغاز می‌شود) شروع می‌کند. سپس، مشابه IPv4 هر دستگاهی در طول مسیر که ام‌تی‌یو ی آن از بسته کوچک‌تر باشد، بسته را رها می‌کند و پیام ICMPv6 *Packet Too Big* (نوع ۲) حاوی ام‌تی‌یو ی خود را به عقب می‌فرستد، که به میزبان منبع اجازه می‌دهد تا ام‌تی‌یو ی مسیر خود را درخور آن کاهش دهد. این روند تکرار می‌شود تا زمانی که ام‌تی‌یو به اندازه کافی کوچک باشد تا بتواند کل مسیر را بدون قطعه قطعه شدن طی کند.

اگر بعد از راه اندازی اتصال، ام‌تی‌یو ی مسیر تغییر کند و کمتر از ام‌تی‌یو ی مسیر تع*یین شده از قبل* باشد، اولین بسته بزرگ باعث خطای ICMP می‌شود و ام‌تی‌یو ی جدید مسیر که کم‌تر است پیدا می‌شود. برعکس، اگر PMTUD متوجه شود که مسیر ام‌تی‌یویی بزرگتر از آنچه در لینک قبل امکان‌پذیر است را مجاز می‌داند، سیستم عامل به‌طور دوره ای مجدداً بازبینی می‌کند تا ببیند آیا مسیر تغییر کرده‌است و اکنون بسته‌های بزرگتر را مجاز می‌داند یا خیر. هم در لینوکس و هم در ویندوز این تایمر به صورت پیش فرض روی ده دقیقه تنظیم شده‌است.

چالش‌ها و مسائل
---------------

بسیاری از *دستگاه های* به اصطلاح *امنیتی شبکه* تمام پیام‌های ICMP را برای مزایای امنیتی شناخته شده مسدود می‌کنند. از جمله خطاهایی که برای عملکرد صحیح PMTUD ضروری هستند. توجه داشته باشید که این امر علی‌رغم این که مقاله ارجاعی به‌طور خاص توصیف *ICMP خوب* را انجام می‌دهد*،* مانند آنچه برای عملکرد صحیح PMTUD لازم است، اتفاق می‌افتد. این می‌تواند منجر به اتصالاتی شود که دست دادن سه طرفه TCP را به درستی کامل می‌کنند، اما پس از انتقال داده‌ها قطع می‌شوند. به این حالت *اتصال سیاهچاله* گفته می‌شود.

برخی از پیاده‌سازی‌های PMTUD تلاش می‌کنند تا با استنباط اینکه بسته‌های بزرگ محموله(payload) به دلیل ام‌تی‌یو، و نه به دلیل ازدحام لینک حذف شده‌اند، از این مشکل جلوگیری کنند. با این حال، برای اینکه پروتکل کنترل انتقال (TCP) کارایی بیشتری داشته باشد، *پیام‌های غیرقابل دسترسی* ICMP (نوع ۳) باید مجاز باشند. یک روش قوی برای PMTUD که به TCP یا پروتکل دیگری برای بررسی مسیر با بسته‌های تدریجاً بزرگتر متکی است، در RFC 4821 استاندارد شده‌است.

راهکاری که توسط برخی روترها استفاده می‌شود تغییر حداکثر اندازه قطعه (MSS) در تمام اتصالات TCP است که از طریق پیوندهایی با ام‌تی‌یو ی کم‌تر از پیشفرض ۱۵۰۰ اترنت عبور می‌کنند. این به عنوان *بستن MSS* شناخته می‌شود.

منابع
-----

1. ↑  RFC 1191, *Path MTU Discovery*, J. Mogul, S. Deering (November 1990)
2. ↑  RFC 1981, *Path MTU Discovery for IP version 6*, J. McCann, S. Deering, J. Mogul (August 1996)
3. ↑  Mogul, Jeffrey; Hinden, Robert (July 2017). "Path MTU Discovery for IP version 6". *tools.ietf.org* (به انگلیسی). ISSN 2070-1721. Retrieved April 15, 2019.
4. ↑  RFC 4821, *Packetization Layer Path MTU Discovery*, M. Mathis, J. Heffner (March 2007)
5. ↑  RFC 8899, *Packetization Layer Path MTU Discovery for Datagram Transports*, G. Fairhurst, T. Jones, M. Tüxen, I. Rüngeler, T. Völker (September 2020)
6. ↑  Davies, Joseph (2012). *Understanding IPv6* (3rd ed.). Microsoft Press. pp. 146–147. ISBN 978-0-7356-5914-8.
7. ↑  linux source code (ipv4) and linux source code (ipv6) see line with "mtu\_expires" 10 \* 60 seconds
8. ↑  Davies, Joseph (2012). *Understanding IPv6* (3rd ed.). Redmond: Microsoft Press. pp. 147. ISBN 978-0-7356-5914-8. OCLC 810455372.
9. ↑  Michael Mullins (2003-10-21). "Prevent hacker probing by blocking ICMP traffic". Retrieved 2013-07-12.
10. ↑  RFC 2923, *TCP Problems with Path MTU Discovery*, K. Lahey (September 2000)
11. ↑  "Circumventing Path MTU Discovery issues with MSS Clamping (for ADSL, cable, PPPoE & PPtP users)". *lartc.org*. Retrieved 2019-04-15.