>>>> "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
