Thanks Jinmei,
But there is still the conflict between the address architecture
and ND at the moment. It may not affect the actual ND spec
but it seems like a confusing contradiction for someone trying to
understand how the ADDRARCH and ND specs fit together.
The was also mentioned in the IAB response to Robert Elz' appeal
(i.e. that ND needs to be clarified or addr arch needs to be modified...).
Hesham
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 27, 2004 2:20 AM
> To: Soliman Hesham
> Cc: IETF Mailing List
> Subject: Re: [2461bis issue 250] Reception of prefix option
> with prefix length > 64
>
>
> Catching up an old topic...
>
> >>>>> On Tue, 10 Feb 2004 07:26:05 -0500,
> >>>>> Soliman Hesham <[EMAIL PROTECTED]> said:
>
> > What should a node do upon reception of a prefix option
> with the prefix
> > length set to a value >64?
>
> > The issue can be stated more accurately to say:
> > What should a host do upon reception of a prefix option
> with the prefix
> > length set to a value != 64?
>
> You appear to focus on the address configuration side of this issue.
> And RFC2461 is quite clear that the prefix handling in RFC2461 should
> be separate from that in RFC2462, so I'd see this as a 2462bis issue
> and not a 2461bis issue.
>
> Regarding rfc2461bis, my impression is that the receiving node must
> accept an prefix information in terms of the ND (2461 or bis) part
> regardless of the prefix length.
>
> For example, assuming a 64-bit interface identifier, if we receive an
> RA containing an prefix information option with 80-bit prefix length
> and with the L and A bits both being set, RFC2462 clearly says that
> the prefix MUST be ignored in terms of address configuration:
>
> If the sum of the prefix length and interface
> identifier length
> does not equal 128 bits, the Prefix Information option MUST be
> ignored.
> (RFC2462 Section 5.5.3, )
>
> However, I think the receiving node should still consider the prefix
> as valid in terms of ND (i.e., consider it as "on-link") and modify
> the next-hop determination accordingly.
>
> The questions are:
>
> 1. is this a correct understanding of the intention of RFC2461?
> 2. if yes, is this a reasonable behavior?
> 3. if yes (for both 1 and 2), should this explicitly be documented in
> rfc2461bis?
>
> And my personal answers are:
>
> yes for 1 (of course. this is my understanding).
> not sure for 2, but I don't oppose to the behavior (though I'll need
> to change my own implementation).
> probably yes for 3.
>
> JINMEI, Tatuya
> Communication Platform Lab.
> Corporate R&D Center,
> Toshiba Corp.
> [EMAIL PROTECTED]
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
