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

[Ole Troan <[e-mail]>]

>>>> "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 brining 802.11p and other 802.3 links?
> 
> I not understand the question?  Please clarify what do you mean (bringing, binning?)  This is for 802.11 mode OCB.  802.11p no longer exists.  802.3 does not need a spec because it has rfc2464.

Fingers stumbling. Bridging.

> The interface 802.11-OCB is not an 802.3 interface.
> 
> Let me try to understand what do you mean?
> 
>> 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