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

[Ole Troan <[e-mail]>]

> 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?
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.

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.

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

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