At Fri, 10 Aug 2007 18:55:18 -0500,
"Leino, Tammy" <[EMAIL PROTECTED]> wrote:
> When I add an address in my OS, I add a network route according to the
> prefix length of the address so I know that other nodes with this same
> prefix are on-link. I don't route based on a source address. I find a
> route for a destination from the routing table based on the destination
> address. If I added a network route for my prefix, and this destination
> matches that prefix, then I find that network route. Otherwise, I find
> the default route and use it. If I receive a redirect, I will create a
> host route for that destination. If I had been able to add a network
> route, I never would have received that redirect and would be saving
> memory by not adding the host route. Can you tell I work on embedded
> systems? I am very stingy with memory!
>
> I will not have a route for a prefix if I do not have an address
> assigned to a local interface containing based on that prefix. If an
> address associated with a prefix is deleted, so is the route.
>
> I appreciate everyone's comments and advice. I am glad to see such
> passion for IPv6 and support of people in need.
You still seem to be confused about the notion of separation between
address configuration and on-link prefix configuration that Bernie
already explained pretty well. It should also be remarked that prefix
information provided by RA does not always mean address configuration
(which, again, Bernie already explained). If one understood these
points, we could easily understand the following quote of the DoD
requirement doesn't actually indicate the need for on-link prefix
information given by DHCPv6:
"All IPv6 Nodes MUST support at least one autonomous method for
discovering its own unique IPv6 interface address(es), either RFC
2462, IPv6 Stateless Address Auto-configuration (SLAAC) or the
client side of RFC 3315, DHCPv6. DHCPv6 provides for a stateful
equivalent to SLAAC. The two methods are complementary but not
mutually exclusive."
That is, it only talks about address configuration but doesn't say
anything about on-link prefix information.
Overall, we should first share the base understanding of the protocol
design before discussing anything new.
Assuming we share the base, points to be discussed are:
- whether we need a way to provide on-link prefix information via
DHCPv6 even if RA already has this provision. I don't see strong
need for this; however, as David mentioned there is a minor void due
to the deprecation of the "on-link by default" rule, and I agree it
at least warrants discussion on the need for this new option. But
even if we introduce the new option I believe it should only cover
very rare cases and host implementation should not assume this
information is always provided via DHCPv6.
- whether we need a way to provide default router addresses via DHCPv6
even if RA already has this provision. I personally don't see any
need for this unlike the case of on-link prefix information. For
that matter, simply saying "there may be a case where there is a
node that forward packets but don't send out RAs" isn't convincing
enough to me (and I'm afraid not to many others). A reasonable
background should also be provided that explains why we ever need
such a seemingly unrealistic scenario. Again, just saying some
authority like DoD is requiring something isn't convincing to me
,and I'm afraid not to many others; besides, as explained above the
DoD statement talking about address configuration methods doesn't
justify the need for this new option in the first place.
In any event, I hear that some DHCPv6 guys are planning to make a new
draft that covers this topic. So I think it's better to hold off for
now and wait for the document, rather than continue this thread
with keeping possible misunderstanding or confusing about the base
protocol principles.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
