At Wed, 15 Aug 2007 10:51:40 -0700,
"David W. Hankins" <[EMAIL PROTECTED]> wrote:
> > > I think that you will find realistically, DHCPv6 servers will know
> > > prefix lengths.
> >
> > None that I've worked with (including the WIDE server) seems to care.
> > What's needed are assignment ranges, not prefixes.
>
> I'm familiar with half of the story here, and uncomfortable with
> speaking about a specific competitor's product (but it appears I will
> do it anyway). My opinion of WIDE's Confirm message processing is
> that it does know the prefix length: it assumes all prefixes are /64,
> by comparing the first 8 bytes of addresses.
>
> I make no judgement here of the efficacy or correctness of this
> implementation.
>
> If there is an expert on WIDE's implementation that can describe how
> it reaches a dynamic pool from relays (without relays, it appears to
> follow interface definitions), I'm curious to know the rest of the
> story.
I'm not an "expert" on the WIDE implementation (any more), but I know
the implementation well enough that I can clarify the points, so...
Your understanding about the Confirm message processing of the WIDE
server is correct. (And I don't think this way of handling Confirm is
really an appropriate behavior).
The WIDE server implementation doesn't care about the link prefix when
assigning an address from a pool. This is also not an appropriate
behavior because it could assign an address that is not valid for the
link to which the client is attached.
So, I think you're right in that realistically the DHCPv6 server
operator needs to understand the link prefixes of the addresses
assigned via DHCPv6. This also means the DHCPv6 server will
realistically be able to provide this information for the clients.
(The server might still work properly just based on the knowledge
about its own local links and on the content of 'link address'
information of relayed messages. But such an operation does not seem
"realistic" to me).
But I don't think this immediately justifies the introduction of
an on-link prefix option to DHCPv6. To rely on this feature, the
DHCPv6 operator would need to know all on-link prefixes including ones
that are not used for DHCP-based address assignment, and would need to
configure them on the server. Although the additional overhead is
minor, it can still be an unnecessary operational cost and can cause
configuration inconsistency that could actually avoided. On the other
hand, routers should inherently know the on-link prefix information to
route packets appropriately, so providing this information via RA
still looks better than the DHCP-based approach.
IMO, this discussion is going to miss the point. The problem is not
whether we can provide on-link prefix information via DHCPv6 (yes we
can) or whether it's reasonable per se (it might), but whether we
should do this while RA already has this provision and would actually
be better than DHCPv6-based approach. A new draft from the dhc group
will reportedly (hopefully?) answer this main question, so, again, I
think we should hold off for a while.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
