Re: [Int-dir] 118

[Alexandre Petrescu <[e-mail]>]

Le 18/04/2019 à 19:14, 神明達哉 a écrit :
> At Thu, 18 Apr 2019 14:05:27 +0200,
> Alexandre Petrescu <[e-mail] 
> <mailto:[e-mail]>> 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