At Thu, 18 Apr 2019 14:05:27 +0200,
Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx> wrote:
> > Now, from the discussion so far, I'm feeling the sense of a desire
> > for IPv6-over-OCB to use other values of IID length than 64 bits.
>
> The desire comes from my deployment of linux on 3 single-link subnets
> needing fe80:1::1 (linux has no zone id, but supports fe80::/32).
>
> I am not sure about the others.
If it's only about the convenience of your specific implementation,
I'd say it's quite weak as a reason for including it in the generic
IPv6-over-OCB specification, despite the cost of updating a change to
a 24-year standard (since RFC1884).
Unless this is something that the pure protocol nature of
IPv6-over-COB requires (which I don't know due to my lack of
full understanding), I personally suggest this specification stick to
the current status quo, i.e., 64-bit IID length, so that new
developers can develop interoperable implementations without
ambiguity. At the very least, this approach doesn't impose any new
procedural bar and will help publish it sooner.
Separately, if you believe your cause is strong enough to change the
current standard, you can try it at 6man so a non-0 value in the
intermediate 54-bit field can be validly used. IPv6-over-COB can be
subsequently updated to reflect that.
But, if you (WG) don't like IPv6-over-COB to be published in an
incompatible way with your own implementation for now, I don't see
other options than hold off until the separate effort at 6man is
completed.
Whether the delay due to that and the uncertainty of its success are
acceptable for IPv6-over-COB is totally up to the WG. I have my own
personal suggestion as stated above, but it's quite possible that the
WG prefers a different option. My bottom line is that the IPv6-over-COB
can't ship with obscuring the IID length.
--
JINMEI, Tatuya
Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx> wrote:
> > Now, from the discussion so far, I'm feeling the sense of a desire
> > for IPv6-over-OCB to use other values of IID length than 64 bits.
>
> The desire comes from my deployment of linux on 3 single-link subnets
> needing fe80:1::1 (linux has no zone id, but supports fe80::/32).
>
> I am not sure about the others.
If it's only about the convenience of your specific implementation,
I'd say it's quite weak as a reason for including it in the generic
IPv6-over-OCB specification, despite the cost of updating a change to
a 24-year standard (since RFC1884).
Unless this is something that the pure protocol nature of
IPv6-over-COB requires (which I don't know due to my lack of
full understanding), I personally suggest this specification stick to
the current status quo, i.e., 64-bit IID length, so that new
developers can develop interoperable implementations without
ambiguity. At the very least, this approach doesn't impose any new
procedural bar and will help publish it sooner.
Separately, if you believe your cause is strong enough to change the
current standard, you can try it at 6man so a non-0 value in the
intermediate 54-bit field can be validly used. IPv6-over-COB can be
subsequently updated to reflect that.
But, if you (WG) don't like IPv6-over-COB to be published in an
incompatible way with your own implementation for now, I don't see
other options than hold off until the separate effort at 6man is
completed.
Whether the delay due to that and the uncertainty of its success are
acceptable for IPv6-over-COB is totally up to the WG. I have my own
personal suggestion as stated above, but it's quite possible that the
WG prefers a different option. My bottom line is that the IPv6-over-COB
can't ship with obscuring the IID length.
--
JINMEI, Tatuya
