Re: [ipwave] [Int-dir] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34 - 'conforming IPv6' - fe80::/10 vs fe80::/64

[Alexandre Petrescu <[e-mail]>]

Le 10/04/2019 à 14:40, Ole Troan a écrit :
>> You said: if OCB is still 48bit, and if there is bridging
>> OCB-Ethernet, then no reason to be different than rfc2464.
>> 
>> I said: OCB is still 48bit, but there is no bridging OCB-Ethernet.
>> 
>> The conclusion is: there is reason to be different from RFC 2464.
> 
> Why?
> 
>> Now, you give a different conclusion.
>> 
>> Excuse me, I would like to clarify this please?
> 
> Clarify what?

You said if OCB-Ethernet bridging then no need of update.  Then you
concluded differently.  That needs clarification.

> That a link-layer that looks an awfully lot like Ethernet

It looks an awful lot like Ethernet, but it can not be bridged to it. 
The 'brctl' and 'brconf' software issue errors when trying to link OCB 
interface to Ethernet interface.

> [That a link-layer that looks an awfully lot like Ethernet] should not
> follow the 64-bit boundary and the definition of the link-local
> address mapping of rfc2464? Section 4.5.1 is already clear on that.

If OCB can not be bridged to Ethernet then OCB interfaces are free to 
have a 65bit IID, without fearing lack of interoperability to an 
Ethernet interface with 64bit IID.  The IP forwarding does not care 
about IID length, and there is no bridging.

> I think the only thing we are asking you is to change the following
> paragraph:
> 
> OLD: A subnet is formed by the external 802.11-OCB interfaces of
> vehicles that are in close range (not by their in-vehicle
> interfaces).  This subnet MUST use at least the link-local prefix
> fe80::/10 and the interfaces MUST be assigned IPv6 addresses of type
> link-local.
> 
> NEW: A subnet is formed by the external 802.11-OCB interfaces of
> vehicles that are in close range (not by their in-vehicle
> interfaces). A node MUST form a link-local address on this link.

Makes sense, I will add it.

Then somebody will ask what is the prefix length of the LL prefix on 
OCB?  What reference should I give to the person asking?

The reference is RFC2464 that says 64bit IID.  But that is for Ethernet 
and EThernet can not be bridged to OCB.

> Not quite sure what value that paragraph adds in the first place. You
> could probable remove it.

The value in mentioning /10 is that it works on OCB (it works also on 
Ethernet but not on all OSs, and so  it may risk violating a section).

Alex


> 
> Cheers, Ole
> 
> 
>> 
>> Alex
>> 
>> Le 10/04/2019 à 12:28, Ole Troan a écrit :
>>> Alexandre, Right, so it doesn’t sound like you have any reason to
>>> be different from RFC2464. Just reference or copy that text
>>> (section 5, rfc2464). Ole
>>>> On 10 Apr 2019, at 11:22, Alexandre Petrescu
>>>> <[e-mail]> wrote:
>>>> 
>>>> 
>>>> 
>>>> Le 10/04/2019 à 11:04, Ole Troan a écrit :
>>>>>>>>> "At least" does not mean "the value should be at
>>>>>>>>> least 10" in that phrase.
>>>>>>>>> 
>>>>>>>>> Do you think we should say otherwise?
>>>>>>>> 
>>>>>>>> To me there is nothing in the actual text to tell me
>>>>>>>> that "at least" qualifies the "/10". I think you could
>>>>>>>> rephrase as "This subnet's prefix MUST lie within the
>>>>>>>> link-local prefix fe80::/10 ..."
>>>>>>>> 
>>>>>>>> However, see Jinmei's messages about conformance with
>>>>>>>> RFC 4291.
>>>>>>>> 
>>>>>>>> I think there might be unexpected side effects from
>>>>>>>> using an address like fe80:1::1. What if some code uses
>>>>>>>> matching with fe80::/64 to test if an address is
>>>>>>>> link-local? I agree that would be faulty code, but you
>>>>>>>> would be the first to discover it.
>>>>>>> Indeed. If you absoultely must cut and paste text from
>>>>>>> 2464:
>>>>>> 
>>>>>> YEs, that is how we started.  We cut and paste from 2464.
>>>>>> 
>>>>>>> 5.  Link-Local Addresses The IPv6 link-local address
>>>>>>> [AARCH] for an Ethernet interface is formed by appending
>>>>>>> the Interface Identifier, as defined above, to the prefix
>>>>>>> FE80::/64. 10 bits            54 bits                  64
>>>>>>> bits 
>>>>>>> +----------+-----------------------+----------------------------+
>>>>>>>
>>>>>>> 
|1111111010|         (zeros)       |    Interface Identifier    |
>>>>>>> +----------+-----------------------+----------------------------+
>>>>>>>
>>>>>>>
>>>>>>> 
I presume there is support for bridging 802.11p and other 802.3 links?
>>>> 
>>>> In the IP-OBUs that I know there is IP forwarding between
>>>> 802.11-OCB (earlier 802.11p) and 802.3, not bridging.
>>>> 
>>>> In some IP-OBU (Internet Protocol On-Board Unit) some non-OCB
>>>> interfaces are indeed bridged.  E.g. the Ethernet interface is
>>>> bridged to the WiFi interface; that helps with DHCP, tcpdump
>>>> and others to see one a single - bridged - interface.
>>>> 
>>>> Bridging may be, but it is not a MUST.  There is no necessarily
>>>> any bridging between the 802.11-OCB interface and other
>>>> interface, neither bridging between the multiple 802.11-OCB
>>>> interfaces that might be present in the same computer.
>>>> 
>>>> Do you assume bridging of 802.11-OCB interface to Ethernet
>>>> interface is always there?
>>>> 
>>>> Note: I also heard many comments suggesting that EAL is akin to
>>>> 'bridging'.  I do not know whether you refer to that
>>>> perspective.  If yes, we can discuss it separately.
>>>> 
>>>> Alex
>>>> 
>>>> [...]
>>>> 
>>>>>>> And that the MAC address length of this link type is also
>>>>>>> 48 bits?
>>>>>> 
>>>>>> YEs, the length of MAC address on 802.11 mode OCB is also
>>>>>> 48.
>>>>>> 
>>>>>>> If the two assumptions above hold, then I see zero
>>>>>>> justification for pushing the 64 bit boundary in this
>>>>>>> draft.
>>>>>> 
>>>>>> Let me try  to understand the first assumption.
>>>>> Ole
>>>> 
>>>> _______________________________________________ Int-dir mailing
>>>> list [e-mail] 
>>>> https://www.ietf.org/mailman/listinfo/int-dir
>> 
>> _______________________________________________ Int-dir mailing
>> list [e-mail] 
>> https://www.ietf.org/mailman/listinfo/int-dir
> 
>