Hello Paul:
Great catch, and I agree.
Ignoring is fine for RPL but not for 6LoWPAN. Let me propose the following
update:
+---------------+----------------------------------------------+
| P-Field Value | Registered Address Type |
+---------------+----------------------------------------------+
| 0 | Registration for a Unicast Address or prefix |
+---------------+----------------------------------------------+
| 1 | Registration for a Multicast Address |
+---------------+----------------------------------------------+
| 2 | Registration for an Anycast Address |
+---------------+----------------------------------------------+
| 3 | Reserved, MUST NOT be used by the sender. |
+---------------+----------------------------------------------+
Table 1: P-Field Values
The intent for the value of 3 is a prefix registration (see
[I-D.ietf-6lo-prefix-registration], which is expected to be published
soon after this specification. At the time of this writing, RPL
already advertises prefixes, and treated unicast addresses as
prefgixes with a length of 128, so it does not really need that new
value. On the other hand, 6LoWPAN ND does not, and the value of 3
meaning prefix registration will not be processed adequately. As a
result:
* When the value of 3 is received in an RTO (see Section 6.5), this
value MUST be ignored by the receiver, meaning, treated as a value
of 0, but the message is processed normally.
* In the case of an EARO (see Section 7.1) or an EDAR (see
Section 7.2), the message MUST be dropped, and the receiving node
MAY either reply with a status of 12 "Invalid Registration" or
remain silent.
Works?
Pascal
Le lun. 29 avr. 2024 à 18:55, Paul Wouters via Datatracker <[email protected]>
a écrit :
> Paul Wouters has entered the following ballot position for
> draft-ietf-6lo-multicast-registration-18: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-multicast-registration/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> This is a bit far outside the field of my expertise, but I did have one
> question.
>
> In section 6.4. New Registered Address Type Indicator P-Field, the value
> '3' states:
>
> Reserved, MUST be ignored by the receiver.
>
> But that means that the packet is not any of the "Registration" values, so
> I am not sure
> what "MUST ignore" means? Wouldn't the entire packet be invalid, eg some
> kind of error?
> That is not really the same as "ignore" which implies "continue with the
> other valid values"
>
>
>
>
--
Pascal
_______________________________________________
6lo mailing list -- [email protected]
To unsubscribe send an email to [email protected]
