الخلاصة

  • يتيح RFC 9686 للأجهزة تسجيل عناوين IPv6 التي أنشأتها بواسطة SLAAC أو ضُبطت عليها بصورة ثابتة. ووفق RFC 9915، ينشئ الخادم لهذا التسجيل عقد إيجار يمثل حالة دورة حياة من جهة الخادم، مع بقاء اختيار العنوان للجهاز؛ فلا يكون العقد دليلاً على أن DHCPv6 خصص العنوان.
  • إنشاء عقد الإيجار الذي يصفه RFC 9915 لا يساوي إنشاء رابطة Client Identifier بالعنوان في RFC 9686؛ فالأخير إجراء موصى به بصيغة SHOULD، لا نتيجة إلزامية يجوز استنتاجها من كل رد.
  • تعني ADDR-REG-REPLY أن الخادم استلم رسالة التسجيل المقبولة بروتوكولياً وأن على العميل وقف إعادة إرسالها. لا تثبت الرسالة أن الخادم أنشأ رابطة أو احتفظ بها، ولا تثبت صلاحية العنوان أو الهوية أو الأصالة أو قابلية الوصول أو الاستخدام المستمر أو وقوع حركة شبكية.
  • لا تمنح حيازة سجلات التسجيل سلطة تلقائية لجمعها بلا حدود، أو دمجها مع بيانات الهوية، أو كشفها، أو اتخاذ إجراء ضد جهاز أو مشترك. ويتوقف أثر الخصوصية على التنفيذ الفعلي: الحقول المسجلة، واستقرار المعرّفات، ومصادر الربط، والجهات المخولة، وفترات الاحتفاظ.

من تخصيص العنوان إلى تسجيله

صدر RFC 9686 في ديسمبر 2024 بوصفه معياراً على مسار معايير IETF ومن عمل مجموعة DHC. يعالج المعيار فجوة تشغيلية مألوفة في IPv6: يستطيع الجهاز تكوين عنوان بواسطة SLAAC، أو استخدام عنوان ثابت، من دون أن يكون خادم DHCPv6 قد اختار ذلك العنوان أو خصصه. تصبح البنية التحتية، نتيجة ذلك، أقل قدرة على الإجابة عن أسئلة الدعم والتحقيق التي اعتادت الإجابة عنها من سجلات DHCP في IPv4.

يقدم RFC 9686 بروتوكول تسجيل داخل إطار DHCPv6. يطلب العميل معرفة ما إذا كانت الشبكة تدعم الآلية، ويعلن الخادم OPTION_ADDR_REG_ENABLE في Advertise أو Reply عندما يكون مهيأً لذلك. من دون هذا الإعلان يجب على العميل ألا يرسل التسجيلات. إعلان القدرة لا يعني أن عنواناً محدداً سُجل؛ إنه يثبت فقط أن البنية التحتية أعلنت استعدادها لاستقبال هذا النوع من الرسائل على الرابط المعني.

بعد تكوين عنوان صالح عالمي النطاق ذاتياً أو بصورة ثابتة، يرسل العميل ADDR-REG-INFORM من العنوان الذي يريد تسجيله. تحتوي الرسالة على Client Identifier وعلى IA Address واحد، وتعرض العمرين المفضل والصالح للعنوان. ولا تدخل عناوين link-local في الآلية، كما لا يسجل العميل بهذه الطريقة عنواناً خصصه DHCPv6 أصلاً.

عقد إيجار، ولكن ليس عقد تخصيص

يحتاج المصطلح إلى دقة خاصة. يقرر القسم 6.6 من RFC 9915، الذي حل محل RFC 8415، أن الخادم ينشئ عقد إيجار لتسجيل العنوان المولد ذاتياً، وأن الجهاز يؤدي أعمالاً دورية مرتبطة بتجديده، ثم يمكن أن ينتهي العقد. لا يصح، بناء على ذلك، القول إن التسجيل لا ينشئ أي عقد إيجار.

لكن وجود العقد لا يغير منشأ العنوان. الجهاز هو الذي اختار عنوان SLAAC أو العنوان الثابت؛ لم يخصصه خادم DHCPv6. عقد الإيجار هنا حالة دورة حياة ينشئها الخادم لتمثيل التسجيل ومتابعة عمره، وليس دليلاً على تخصيص العنوان بواسطة DHCPv6. والفصل بين الأمرين ضروري في التحقيق وفي إدارة الموارد: «الخادم أنشأ عقد تسجيل لهذا العنوان» لا تساوي «الخادم منح هذا العنوان للعميل».

ويجب كذلك عدم دمج عقد الإيجار مع رابطة Client Identifier بالعنوان في مفهوم واحد. يقول RFC 9686 إن الخادم SHOULD أن ينشئ هذه الرابطة إذا لم تكن موجودة؛ أي إن إنشاءها موصى به، وليس التزاماً مطلقاً. أما RFC 9915 فيصف إنشاء عقد الإيجار بصيغة تقريرية صريحة. وقد يمثل التنفيذ عقد الإيجار والرابطة داخل بنية بيانات واحدة، لكن هذا اختيار تنفيذي لا يزيل الفرق المعياري بينهما.

هذه الدقة تمنع ثلاثة أخطاء: إنكار وجود عقد الإيجار، واعتباره دليلاً على أن DHCPv6 اختار العنوان، وافتراض أن كل ADDR-REG-REPLY يثبت بالضرورة إنشاء رابطة قابلة للاستعلام لاحقاً. الحقيقة التقنية أضيق: الاختيار لدى الجهاز، ودورة حياة التسجيل لدى الخادم، والرابطة إجراء موصى به.

ما الذي يقبله الخادم؟

يجب أن يرفض الخادم ADDR-REG-INFORM إذا غاب Client Identifier، أو ظهر Server Identifier، أو غاب IA Address، أو لم يطابق العنوان المعلن مصدر الرسالة الأصلية، أو احتوت الرسالة على Option Request. عند استخدام المرحلات، تكون المقارنة مع peer-address في أعمق Relay-forward؛ ومن دون مرحل تكون مع عنوان مصدر الحزمة.

أما فحص ملاءمة العنوان للرابط أو وقوعه ضمن بادئة مفوضة للعميل فهو موصى به بصيغة SHOULD، وليس شرطاً إلزامياً مطلقاً في كل تنفيذ. إذا أجرى الخادم هذا الفحص وفشل العنوان فيه، وجب عليه إسقاط الرسالة بصيغة MUST، واستُحسن أن يسجل الفشل بصيغة SHOULD. هذه الصياغة مهمة للحوكمة: لا يجوز لسجل التدقيق أن يوحي بأن فحص الرابط حدث ما لم يكن التنفيذ قد أجراه فعلاً.

بالنسبة إلى التسجيل المقبول، يجب على الخادم تسجيل معلومات الحدث ما لم يكن مهيأً لتعطيل التسجيل في السجل. ويُستحسن أن يسجل DUID وعنوان طبقة الربط عند توفره. كما يُستحسن أن ينشئ رابطة بين Client Identifier والعنوان، وأن يجعل العنوان غير متاح للتخصيص وألا يدرجه في عروض لاحقة. أما إرسال ADDR-REG-REPLY فهو إلزامي.

لذلك لا يمكن استنتاج جميع هذه الآثار من مجرد وجود الرد. تسجيل الحدث إلزامي مع استثناء الإعداد الذي يعطل التسجيل؛ وإنشاء الرابطة موصى به؛ وجعل العنوان غير متاح للتخصيص موصى به؛ والرد واجب. وعلى نظام الأدلة أن يسجل ما فعله التنفيذ فعلاً وأي خيارات كانت مفعلة، بدلاً من ملء الفجوات بافتراضات.

حدود ADDR-REG-REPLY

ينسخ الرد معرّف المعاملة ويحتوي IA Address المطابق. وظيفته إثبات استلام ADDR-REG-INFORM المقبول وإخبار العميل بالتوقف عن إعادة الإرسال. وينص RFC 9686 على ألا يُعد الرد دليلاً على صلاحية العنوان، وألا يكون شرطاً لاستخدامه، وألا تنشئ المرحلات أو الأجهزة التي تراقبه حالة توجيه أو أمن بسببه.

وبناء على ذلك، لا تثبت الرسالة وحدها:

  • أن الخادم أنشأ رابطة Client Identifier بالعنوان؛
  • أن الرابطة، إن أُنشئت، ظلت محفوظة إلى وقت لاحق؛
  • أن العنوان صالح فعلاً أو فريد بصورة مطلقة؛
  • أن الجهاز أصيل أو أن Client Identifier غير منتحل؛
  • أن العنوان قابل للوصول من شبكة أو خدمة معينة؛
  • أن العميل أنتج حزمة تطبيقية محل تحقيق؛
  • أن الاستخدام استمر طوال العمر المعلن؛
  • أن حساباً أو مشتركاً أو إنساناً بعينه كان الفاعل؛
  • أن النشاط مسموح أو مخالف للسياسة؛
  • أن الجهة الحائزة للسجل مخولة بالعزل أو الإفصاح أو العقوبة.

تنتمي هذه الأسئلة إلى نظم إثبات وسلطات مختلفة. يحسن التسجيل قابلية الرصد، لكنه لا يختصر المسافة بين مشاهدة تقنية وإسناد مؤسسي.

الزمن: الموعد المحسوب ليس موعد إرسال مضموناً

تحتاج آلية تحديث SLAAC إلى قراءة دقيقة. بعد تسجيل العنوان أو تحديثه، يحسب العميل NextAddrRegRefreshTime انطلاقاً من 80% من Valid Lifetime الحالية، مضروبة في عامل عشوائي بين 0.9 و1.1 لتقليل تزامن العملاء. غير أن هذا الحساب لا يجدول في حد ذاته تحديثاً أولياً.

تحدث الجدولة عندما تغير الشبكة Valid Lifetime للعنوان بأكثر من 1%، كأن تصل Router Advertisement بقيمة تغير وقت الانتهاء المتوقع. عندئذ يحدد العميل الموعد باستخدام الأصغر بين الوقت الجديد المحسوب والموعد السابق. أما إذا كانت قيمة العمر تنخفض مع مرور الوقت فقط بحيث يبقى وقت الانتهاء المتوقع نفسه، فقد لا يُرسل أي تحديث، لأنه غير ضروري لإبقاء الخادم على معرفة صحيحة بوقت الانتهاء.

ومن ثم لا يجوز اعتبار مرور 80% الاسمية من العمر من دون مشاهدة ADDR-REG-INFORM جديد دليلاً، وحده، على تعطل العميل أو فقد الرصد. ينبغي أولاً معرفة ما إذا تغير وقت الانتهاء المتوقع فعلاً، وما إذا تجاوز التغير هامش 1%، وما إذا نشأت واقعة تقتضي الجدولة.

بالنسبة إلى العنوان الثابت، تكون فترة تحديث التسجيل الافتراضية أربع ساعات ويمكن ضبطها. وإذا أرسل العميل عمراً صالحاً صفرياً، وجب على الخادم معاملته كعنوان منتهي الصلاحية. وعند انتهاء رابطة Client Identifier بالعنوان، يجب على الخادم حذفها واعتبار العنوان متاحاً. هذه قواعد للحالة التشغيلية، وليست بذاتها سياسة للاحتفاظ بالسجل التاريخي.

التفرد والارتباط والهوية

ينظم RFC 4862 تكوين عناوين IPv6 ذاتياً واكتشاف تكرار العنوان. يختبر DAD غياب تكرار ظاهر على الرابط قبل إسناد العنوان إلى الواجهة، لكنه لا يصادق الجهاز أو المستخدم، ويمكن تعطيله إدارياً، ولا يمنح ضماناً أبدياً ضد التكرار أو الانتحال.

ويمكن لـFCFS SAVI، وفق RFC 6620، ربط عنوان المصدر بمرساة من الطبقة الثانية داخل محيط حماية محدد. يفرض المعيار استخدام منفذ المحول مرساةً للربط، ويحذر من أن الحل ليس أقوى من المرساة. فإذا اشتركت أجهزة خلف منفذ واحد، لم تعد المرساة تميز بينها بالقوة نفسها. كما أن الثقة داخل محيط SAVI لا تنتقل تلقائياً إلى حركة لم تمر بنقطة التحقق.

وعندما يعمل FCFS SAVI وفق النموذج المحدد، يذكر RFC 9686 أن خادم DHCPv6 يستطيع الوثوق بأن رسالة التسجيل صدرت من الحائز الشرعي للعنوان داخل ذلك المحيط. إلا أن «الحائز الشرعي» في سياق التحقق من مصدر العنوان لا يعني شخصاً طبيعياً معلوماً، ولا يقرر الغرض المسموح لاستخدام الجهاز، ولا يمنح سلطة جزائية.

مصفوفة الحيازة والدلالة

الواقعة أو السجل الحارس التقني المحتمل الدلالة المحدودة السلطة التي لا تنشأ تلقائياً
إعلان OPTION_ADDR_REG_ENABLE خادم DHCPv6 دعم التسجيل على الرابط جمع بيانات غير محدودة أو ربطها بالهوية
ADDR-REG-INFORM الخادم أو المرحل ادعاء عميل بعنوان وعمر محددين إثبات الشخص أو الاستخدام الفعلي
عقد إيجار التسجيل خادم DHCPv6 حالة دورة حياة أنشأها الخادم إثبات تخصيص DHCPv6 للعنوان
ADDR-REG-REPLY العميل والخادم الاستلام ووقف إعادة الإرسال إثبات الرابطة أو الصلاحية أو الوصول
رابطة SAVI محول أو وظيفة تحقق ارتباط محلي بمرساة ضمن المحيط إسناد النشاط إلى إنسان
Neighbor Cache تاريخي الموجه أو نظام الإدارة اقتران عنوان شبكي بعنوان طبقة ربط في وقت معين إثبات ملكية الجهاز أو قصد المستخدم
IPFIX أو سجل تطبيق جامع التدفقات أو التطبيق مشاهدة حركة أو حدث إثبات أن العميل المسجل هو منشئه
RADIUS أو المصادقة نظام الهوية ارتباط حساب بجلسة أو منفذ إثبات أن صاحب الحساب نفذ النشاط
سجل قرار آلي منصة أمن أو إدارة أن قاعدة معينة أطلقت إجراء مشروعية القاعدة أو صحة الإسناد

توضح المصفوفة أن الحارس التقني ليس بالضرورة صاحب السلطة التنظيمية. قد يدير فريق الشبكة الخادم، لكن ذلك لا يخوله تلقائياً كشف السجلات للموارد البشرية. وقد يستطيع فريق الأمن دمجها مع RADIUS، لكن القدرة البرمجية على الربط لا تجيب عن غرض المعالجة أو مدة الاحتفاظ أو حق الشخص في الاعتراض والتصحيح.

الخصوصية تتبع البنية الفعلية

لا ينتج عن RFC 9686 أثر خصوصية واحد متماثل في جميع الشبكات. يتوقف النطاق على ما ينشره المشغل فعلاً: هل يسجل DUID أو عنوان طبقة الربط؟ هل ينشئ الرابطة الموصى بها؟ هل يحتفظ بتاريخ التسجيلات بعد انتهاء الحالة الحية؟ هل يربطها بـSAVI أو Neighbor Cache أو RADIUS أو سجلات التطبيقات؟ من يستطيع إجراء الاستعلام، وهل توجد مراجعة أو فصل بين الجهات؟

قد يؤدي تدوير عناوين الخصوصية إلى تقليل ثبات عنوان واحد أمام بعض المراقبين. لكن إذا كانت البنية تسجل كل عنوان دوري وتجمعه تحت Client Identifier مستقر نسبياً ثم تربطه بالمنافذ والمصادقة، فقد تستطيع الجهة المشغلة إعادة بناء استمرارية الجهاز. وإذا كان التسجيل محدود الحقول، قصير الاحتفاظ، غير مدمج بمصادر هوية، فقد يكون الأثر مختلفاً بدرجة كبيرة.

لذلك لا ينبغي القول إن RFC 9686، بمجرد نشره، ينشئ ملفاً دائماً عن المستخدم، ولا إنه محايد خصوصياً في كل الأحوال. السؤال الصحيح هو ما الذي يجمعه التنفيذ، وما مدة بقائه، وما إمكان ربطه، ولأي جهات وغرض. كلما اتسع الربط وطال الاحتفاظ واستقرت المعرّفات، ازدادت القدرة على إعادة بناء النشاط؛ وكلما ضُيقت هذه العناصر، تقلصت تلك القدرة مع ما قد يصاحب ذلك من تراجع في إمكان التحقيق المتأخر.

سجل أدلة قابل للتدقيق

قبل استعمال بيانات التسجيل في إسناد مهني، ينبغي أن يستطيع الملف الإجابة عن الأسئلة الآتية:

  • هل أعلنت القدرة على الرابط المحدد وفي الفترة ذات الصلة؟
  • هل حُفظت رسالة التسجيل الأصلية، أم لا يوجد سوى صف مشتق في قاعدة البيانات؟
  • هل طابق IA Address مصدر الرسالة أو peer-address في أعمق مرحل؟
  • هل نفذ الخادم فحص ملاءمة الرابط أو البادئة فعلاً، وما نتيجته؟
  • هل كان تسجيل الأحداث مفعلاً، وهل أُنشئت الرابطة الموصى بها فعلياً؟
  • ما العمر الصالح، وهل تغير وقت الانتهاء المتوقع بما يستلزم جدولة تحديث؟
  • هل فُهم حساب 80% بوصفه حساباً لموعد محتمل، لا وعداً بإرسال تحديث؟
  • هل توجد مشاهدة مستقلة للحزمة أو التدفق من IPFIX أو التطبيق؟
  • ما سياق Neighbor Cache وSAVI والمنفذ في اللحظة نفسها؟
  • ما الذي تثبته المصادقة، وما الذي يبقى استنتاجاً عن الإنسان؟
  • من أجاز دمج المصادر، ومن راجع القرار، وما وسيلة التصحيح أو الاعتراض؟

توصي RFC 9099 بالنظر إلى مصادر متعددة في تشغيل أمن IPv6، منها IPFIX وNeighbor Cache وسجلات DHCPv6 وSAVI والمنافذ وجدران الحماية والمصادقة وRADIUS، مع مراعاة الخصوصية والاحتفاظ. قيمة التعدد ليست جمع أكبر قدر ممكن من البيانات، بل اختبار مصدر بمصدر مستقل وكشف الفجوات والتعارضات.

المصادر