>> draft 08-16: type, length, an IPv6 address and suboptions, type # = 201
>> draft 17-18: type, length and an IPv6 address, type # = 201
>There is no difference. There were no valid suboptions defined for
>earlier drafts, even though the field was shown as possibly there
>for future suboptions. In the drafts after 16, a reasonable implementation
>should still allow for future suboptions that don't exist yet.
i don't think draft 17/18 implementation will allow suboptions.
see the 17/18 languge about HAO option length. if we follow this,
there's no chance we will see suboptions.
you have to take a security stance. having loose inbound packet
validation == more chances for security vulnerabilities.
draft 17/18 implementations that allow option length != 16 are buggy.
> Option Type
>
> 201 = 0xC9
>
> Option Length
>
> 8-bit unsigned integer. Length of the option, in octets,
> excluding the Option Type and Option Length fields. This field
> MUST be set to 16.
>> no wonder vendors ship without HAO support, it is impossible to
>> support something that changes this often. as for *BSD/KAME, it is
>> decided that we won't merge anything related to mobile-ip6 into main
>> *BSD distribution until mobile-ip6 becomes RFC (so it won't show up
>> onto ExtremeWare, JunOS, MacOS X, ...).
>> if i remember correctly WinXP is shipping with HAO support, i'm not
>> sure which draft it is based.
>I hope things change after we have Proposed Standard and a number
>of interoperable implementations. I regret that your experience has
>caused discomfort. However, it is the nature of IETF Internet Drafts
>that they often change. Even Proposed Standards change. In fact,
>if I remember right, there is even now some movement towards
>changing the Draft Standard about site local addresses.
when moving from PS to DS, they *remove* functionality. they usually
don't mandate new things. your example above does not convince me.
i'm very concerned about the use of MUST for HAO since mobile-ip6 draft
18 is trying to mandate new thing to all IPv6 (RFC2460) implementations.
SHOULD for HAO is okay for me, but MUST for HAO is unacceptable at
this stage of RFC2460-based IPv6 deployment.
itojun
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
