Thomas,
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 believe this should be clarified somewere, e.g., in the IPv6 node reqt's
document. The challenge is in specifying something that is neither too
precise that it precludes legitimate functionality nor too broad that
it opens the door to security holes and/or misconfigurations. In particular,
if it's not OK for a node to configure an address from an advertised prefix
with the "L" bit not set we should probably say so somewhere and give some
rationale.
Regards,
Fred
[EMAIL PROTECTED]
Thomas Narten wrote:
"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]
--------------------------------------------------------------------
