6. Updating RFC 6550

この文書は IPv6 Neighbor Discovery と関連する 6LoWPAN/RPL 仕様を更新し, ノードが近隣ルータへ IPv6 prefix を登録できるようにします. 重要なプロトコル詳細は RFC 原文の形で以下に保持します.

6.  Updating RFC 6550

   [RFC6550] uses the Path Sequence in the Transit Information Option
   (TIO) to retain only the freshest unicast route and remove stale
   ones, e.g., in the case of mobility.  [RFC9010] copies the TID from
   the EARO into the Path Sequence, and the ROVR field into the
   associated RPL Target Option (RTO).  This way, it is possible to
   identify both the registering node and the order of registration in
   RPL for each individual advertisement, so the most recent path and
   lifetime values are used.

   [RFC9685] requires the use of the ROVR field as the indication of the
   origin of a Target advertisement in the RPL DAO messages, as
   specified in Section 6.1 of [RFC9010].  For anycast and multicast
   advertisements (in NS or DAO messages), multiple origins may
   subscribe to the same address, in which case the multiple
   advertisements from the different or unknown origins are merged by
   the common parent.  In that case, the common parent becomes the
   origin of the merged advertisements and uses its own ROVR value.  On
   the other hand, a parent that propagates an advertisement from a
   single origin uses the original ROVR in the propagated RTO, as it
   does for unicast address advertisements, so the origin is recognized
   across multiple hops.

   This specification updates [RFC6550] to require that, for prefix
   routes, the Path Sequence is used between and only between
   advertisements for the same Target and from the same origin (i.e.,
   with the same ROVR value); in that case, only the freshest
   advertisement is retained.  However, the freshness comparison cannot
   apply if the origin is not determined (i.e., the origin did not
   support this specification).

   [RFC6550] uses the Path Lifetime in the TIO to indicate the remaining
   time for which the advertisement is valid for unicast route
   determination, and a Path Lifetime value of 0 invalidates that route.
   [RFC9010] maps the Address Registration lifetime in the EARO and the
   Path Lifetime in the TIO so they are comparable when both forms of
   advertisements are received.

   The RPL router that merges multiple advertisements for the same
   prefix MUST use and advertise the longest remaining lifetime across
   all the origins of the advertisements for that prefix.  When the
   lifetime expires, the router sends a no-path DAO message (i.e., the
   lifetime is 0) using the same value for the ROVR value as for the
   previous advertisements.  This value refers to either the single
   descendant that advertised the Target if there is only one or the
   router itself if there is more than one.

   Note that the Registration Lifetime, TID, and ROVR fields are also
   placed in the EDAR message, so the state created by EDAR is also
   comparable with that created upon an NS(EARO) or a DAO message.  For
   simplicity, the text below mentions only NS(EARO) but it also applies
   to EDAR.