"Fred L. Templin" <[EMAIL PROTECTED]> writes:
> >>I wonder if the setting of the "L" bit in Prefix Information options
> >>also bears some mention in this section. RFC 2461, section 4.6.2 says:
> >>
> >> "When (the L bit is) not set, the advertisment makes no statement
> >> about on-link or off-link properties of the prefix. For instance,
> >> the prefix might be used for address configuration with some of
> >> the addresses belonging to the prefix being on-link and others
> >> being off-link."
> >>
> >>Does this mean that prefix information options with the L bit not
> >>set can be used to auto-configure off-link global or site-local
> >>addresses?
No. The wording really does says what it is supposed to say. If the L
bit is is not set, one cannot say anything about whether the prefix is
on-link or off link. Specifically, a sender cannot assume that other
addresses covered by that prefix are on-link and send packets directly
to them; instead, packets for those destinations must be sent to a
router.
But it may (or may not) be the case that the destination is on the
same link as the original sender. If it is, the router will forward
the packet back to the same link. It may (or it may not) also send a
redirect to the sending node.
This is a feature that allows a router to arrange to have all traffic
forwarded to it, even for destinations that are directly reachable.
It also (possibly) helps support things like multi-link subnets, where
some destinations may be on one link, but others on a different link,
but both covered by the same prefix.
> > Do you have some suggestion of text to add?
> Unfortunately no, because RFCs 2461 and 2462 are both ambiguous on
> the subject. RFC 2461, section 6.3.4 ("Processing Received Router
> Advertisements") says:
> Prefixes with the on-link flag set to zero would normally have the
> autonomous flag set and be used by [ADDRCONF].
> But, [ADDRCONF] (i.e., RFC 2462) says nothing about how to handle
> prefix options with the on-link flag ("L") set to zero!
The point is that if the bit is set, one assumes all destinations
covered by the prefix are on link. If it is not set, you can't assume
that and one does nothing.
> I believe the Node Requirements document is the right place to resolve
> the ambiguity; I'm just not sure what that resolution should be.
Does the above explanation help? I.e., do you still believe there is
an ambiguity?
Thomas
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
