Le 18/04/2019 à 19:14, 神明達哉 a écrit :
At Thu, 18 Apr 2019 14:05:27 +0200,
Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx
<mailto: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),
fe80:1::1 is not something in the pure nature of IPv6-over-OCB.
It is something I designed in the addressing architecture for convoy.
It is implemented with the vanilla linux IP stack on top of OCB MAC and
PHY. The implementation is like this: ifconfig eth0 add fe80:1::1.
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.
This is your recommendatio, but not the recommendation from AD. The
recommendation from AD, if I understand it correctly, is to stay silent
about this, and get the IID length through 6man.
With respect to your recommendation: why do you recommend to respect the
54 0 bits in RFC4291 when these bits are only implemented in BSD, and
BSD does not implement OCB? Is this recommendation appropriate?
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.
YEs, let us try that.
I would like to ask you: would you support such a proposal in 6man?
OR are you redirecting me there in the hope 6man will discard my
proposal and I come back to your initial suggestion?
(the ping pong effect)
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.
Again, if IPv6-over-OCB says fe80:1::/32 is ok it is ok with linux.
You talk about some unknown implementation (BSD) which does not
implement OCB at all.
(I do know BSD is a widespread OS and largely used elsewhere, but it has
no OCB support; I also know it is probably the first IPv6 implementation
in BSD).
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.
Let us unobscure it through 6man.
If you think you will not support this unobscuring in 6man (make 54bits
non-zero), then I think your advice is very misleading. It is not good
to listen to such advice that leads to ping pong effect.
Alex
--
JINMEI, Tatuya
