>>>>> On Tue, 18 Feb 2003 13:56:36 -0800,
>>>>> "Fred L. Templin" <[EMAIL PROTECTED]> said:
>> I have myself been confused by the L bit in the past but I don't think
>> there is anywhere near as much ambiguity here as you. And, if there is
>> the node requirements document isn't the place to fix it.
>>
>>> I'm still of the opinion that some ambiguity exists. Namely, if a prefix
>>> option has the Autonomous flag ("A" bit) set and the on-link flag ("L" bit)
>>> NOT set, one could infer from reading RFC 2462, section 5.5 that it is OK
>>> to go ahead and configure an address from the (off-link) prefix as specified
>>> in 5.5.3 d). But then, which link would one derive an interface identifier
>>> from in order to form an address? (And, which interface would one assign
>>> the address to?)
I agree with Tim (and perhaps Thomas). I don't see any ambiguity in
RFC 2461 and RFC 2462 on this point.
>> It is correct to infer that one should configure an address from a prefix
>> option with the A bit set and the L bit clear. Is it really necessary to
>> spell out that the address should be configured on the interface on which
>> the advertisement was received? What would justify making any other choice?
> Right now, all RFC 2462 (section 5.3.3) says is to go ahead and configure
> addresses for prefix options with the "A" bit set; the "L" bit is don't-care.
> But, RFC 2461 (section 6.3.4) says that "a prefix information option with the
> on-link flag set to zero conveys no information concerning on-link determination",
> i.e., you can't tell whether the prefix is on/off link. But, if you configure an
> address from a prefix option with the "L" bit set to zero and assign it to the
> interface the RA arrived on, you are in effect declaring that at least one /128
> chunk of the prefix is on-link. But, I don't see any text in RFC 2461 that says
> you can assume this. This is where I see the ambiguity.
I don't see why we need to declare one /128 chunk. Perhaps you are
just confused about a "on-link" prefix and a prefix (of the same
length) as a base of address configuration. These two are, at least
conceptually, orthogonal, which is very clear to me from the spec.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
