In-line...
On Oct 16, 2008, at Oct 16, 2008,5:48 PM, Iljitsch van Beijnum wrote:
On 16 okt 2008, at 16:52, Ralph Droms wrote:
My understanding is (and I would happily have my understanding
corrected) that there should *never* be a prefix length associated
with address assignment, whether that address comes from DHCPv6,
manual address assignment, etc. Prefix length is not an attribute
of an address
Well, that would make sense in an architecture like CLNP where
traffic between any two hosts initially flows through a router until
the router sends a redirect, and routers know host addresses through
a host-router "routeing" protocol (ES-IS).
I did not mean to imply anything about requiring IP traffic to be
forwarded through a router, even initially. My understanding is that
the sending node matches the destination address against the Prefix
List for interface; that Prefix List identifies all the prefixes
assigned to the link to which the interface is attached. Each entry
in the Prefix List has an associated prefix length, which is used to
limit the bits used in the match. If the Prefix List entry that
matches the destination indicates that the destination is on link, the
node delivers the datagram directly to the destination.
My point is that the Prefix List is logically separate from any
addresses assigned to an interface. There may be prefixes in the
Prefix List from which the node has no addresses assigned to an
interface, and there may be addresses assigned to the interface that
are not taken from any prefix in the Prefix List.
The Prefix is (usually) populated through RAs. Some stacks make an
assumption that any assigned address must have a corresponding prefix
on the link. By associating a prefix length with that assigned
address, the stack can deduce a prefix, infer that the deduced prefix
is assigned to the link and add the prefix to the Prefix List. This
We have already seen one example stack where an address assigned
through DHCP has caused a corresponding /64 to appear in the Prefix
List, even though the prefix was not advertised in any RA. This
behavior was interpreted as a bug and has been fixed by the vendor.
Extrapolating to DHCPv6, there is no reason for DHCPv6 to assume that
an assigned address is necessarily taken from a prefix assigned to the
link. Address assignment and on-link prefixes are separate and should
be configured separately through DHCPv6. We could allow for the
shorthand, as the usual case will be that the prefix of an assigned
address will be on-link; an extension might be to use a prefix length
of 0 to indicate that the address is not taken from an on-link
prefix. But, DHCPv6 would still need a mechanism to inform the client
node about other prefixes from which no addresses have been assigned
through DHCPv6. Seems cleaner to me to keep the address assignment
mechanism separate from the on-link prefix mechanism. Therefore, my
strong recommendation would be to leave the DHCPv6 address assignment
mechanism unchanged and add a new, separate mechanism for informing
the node about on-link prefixes.
But in the IP architecture, a system knows which other systems it
can communicate with directly by virtue of the subnet prefix. For
hosts you could argue that they can always send packets to a router,
so they don't really have to know whether an address is directly
attached to the local subnet. (And in this case redirects are
possible with IPv6.) But in the IP architecture, there is no
difference in this regard between hosts and routers, so if other
hosts don't know a certain address is present on the local subnet,
routers also don't know this.
More practically, how do you configure an interface if you don't
know the subnet mask? Having the address and the subnet mask become
available separately is very inconvenient in this regard.
I think many stacks already support the shorthand in which a prefix
length included with a manual address assignment indicates that the
prefix derived from the address is assigned to the link. The problem
arises when, perhaps through an API, the stack assumes a /64 prefix
from an assigned address.
- Ralph
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
