>>>>> On Wed, 07 Dec 2005 10:22:29 -0800,
>>>>> YT <[EMAIL PROTECTED]> said:
> Now I have a question about the macro of IN6_IS_ADDR_LINKLOCAL.
> Accroding KAME implementation, in kame/sys/netinet6/in6.h,
> IN6_IS_ADDR_LINKLOCAL is defined as:
> #define IN6_IS_ADDR_LINKLOCAL(a) \
> (((a)->s6_addr[0] == 0xfe) && (((a)->s6_addr[1] & 0xc0) == 0x80))
> In this case, the linklocal address would be
> in the range of 'fe80:' - 'febf:'.
> fe80 : 1111 1110 1000 0000
> febf : 1111 1110 1011 1111
> On the other hand, according to 2.5.6 of RFC3513, link local address
> is defined as:
> | 10 |
> | bits | 54 bits | 64 bits |
> +----------+-------------------------+----------------------------+
> |1111111010| 0 | interface ID |
> +----------+-------------------------+----------------------------+
> In this case, the linklocal address must be 'fe80:0:0:0::/64'.
> Does anybody know why KAME implementation doesn't verify if 54 bits is
> zero.
Because IN6_IS_ADDR_xxxx() macros return true/false based on whether
the address is **of the specified type** (see RFC3493), and **the type
of these addresses*** is determined by the corresponding prefix.
Regarding link-local unicast addresses, it's fe80::/10 (see Section
2.4 of draft-ietf-ipv6-addr-arch-v4-04.txt).
If these macros were to "validate" the address format based on the
address architecture document (in addition to determining the address
type), the implementation of these macros would be much more
complicated. For example, since draft-ietf-ipv6-addr-arch-v4-04.txt
specifies the 9th bit of an IPv6 multicast address be initialized to
0, the "validating" version of IN6_IS_ADDR_MULTICAST() would need to
check whether this bit is 0, in addition to the given address matches
ff00::/8. I don't think the complexity worth the workload.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
---------------------------------------------------------------------
The IPv6 Users Mailing List
Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]
