Re: [6lo] 6CIO in rfc 6775 update

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Adrian and Carsten

I agree I was too quick here; legacy 6LRs will not place a 6CIO but we can live with it. If we MUST the 6 CIO option in RA then the lack of it can be understood as not supporting this specification.

Con of 6CIO: This is more bits in the air for each RA, higher chance of loss.

Con of T flag: more complex logic; overloads the T flag which is there for TID; forces the first NS to be backward compatible.

The last argument is important; we have the open question on AP-ND whether we can make the RUID larger. With the 6CIO method we could.

All in all I’m happy to MUST the 6 CIO and abandon the second method. What do others think ?

Pascal

Le 26 févr. 2018 à 22:09, Adrian Farrel <[e-mail]<mailto:[e-mail]>> a écrit :

I'm not clear, about this, but presumably the presence of a 6CIO is backward compatible. That is, an implementation that does not support 6CIO but receives one does not crash, and either ignores it or tells the sender that something odd was received.

So 6CIO serves much the same purpose as the T-flag and it seems (to me!) you could use on or the other (or both, as you have done!)

I tend to disagree with Carsten that putting flags in MBZ fields typically has worse backwards compatibility. They were defined as MBZ (must ignore) specifically to be forward compatible with new usage.

Adrian

From: Pascal Thubert (pthubert) [mailto:[e-mail]]
Sent: 26 February 2018 18:01
To: [e-mail]<mailto:[e-mail]>
Cc: Adrian Farrel ([e-mail]<mailto:[e-mail]>)
Subject: 6CIO in rfc 6775 update

Dear all

Quoting Adrian’s RTG DIR review:


> 7.1.2

>

>    One alternate way for a 6LN to discover the router's capabilities is

>    to start by registering...

>

> You went to a lot of trouble to define the E-flag. You then made the use of the

> 6CIO (and hence the E-flag) only a SHOULD, and you defined an alternate

> mechanism. (Note: you say "one alternate" implying there are

> more!)

>

> Choice is not good. It complicates the specification and the implementation.

> Why go there? Can't you settle on one mechanism and make it necessary and

> sufficient?

>

https://tools.ietf.org/html/draft-ietf-6lo-rfc6775-update-14#section-7.1.1 defines new capability bits for use in the 6CIO,  which was introduced by RFC7400 to announce support of the spec.
When there is no 6CIO, there’s a plan B using EUI-64 as RUID and IID in a NS(EARO), which is fully backward compatible, and see if the response has an EARO or not from the T flag.
Adrian indicates that a double mechanism is complexity. For backwards compatibility we need to be able to live without 6CIO. Still 6CIO seems to be a good mechanism to generalize and that’s why we used it.

So should we keep the CIO mechanism, or should we drop it?

Pascal