On Tue, Aug 14, 2007 at 08:54:13AM -0400, James Carlson wrote:
> > That may very well be, but if DHCP servers give out addresses, then  
> > this particular can of worms is already open and you have to deal  
> > with it.
> 
> If they provide addresses (they needn't do so), then they need to be
> configured with lists and/or ranges of addresses to provide.  They
> don't need to know about the full prefix extent, nor do they need to
> know the IP addresses of the operable IPv6 routers on the network.

They effectively do, actually, one way or the other.  The server has
to give out an address that is appropriate for the link to which the
client is attached, and it needs to be able to Confirm the use of
addresses, which it may not have allocated.

So you either:

        - Know all broadcast domains.

        - For each domain, know all prefixes and their lengths.

Or:

        - Have a list of all the 'link-address' fields that all
          operating DHCPv6 relays will use to identify a link.

        - For each 'link-address', a list of all appropriate addresses
          for the link (possibly compacted by "contiguous range" or,
          dare we say, prefix length).

        - A second list, this time of all appropriate addresses that
          might be allocated by other servers operating on the
          network.

One of these is easy, the other is rediculously menial.

I think that you will find realistically, DHCPv6 servers will know
prefix lengths.


> > Now if we can manage for all that to happen correctly, why not finish  
> > the job and tell the host about the subnet size?
> 
> Because we already have a perfectly good protocol to do that -- RAs
> already contain that information, so there's no need to duplicate it.

Surely, there must also be some need to perpetuate two protocols,
other than to simply perpetuate the need not to duplicate their
contents?


> > 2. For authentication, authorization and control. I.e., as an ISP, I  
> > want to know which IPv6 belongs to which customer. The interesting  
> > part here is that it's not necessary for the DHCPv6 server to come up  
> > with the address. What we need is that some central server learns  
> > about all the addresses. The crucial difference here is that handing  
> > out addresses has the potential for routing problems, while learning  
> > addresses that the host got through other means (probably stateless  
> > autoconf) is just as useful but without the potential for trouble
> 
> That sounds like IPv4 thinking to me.  If I were an ISP, I'd be
> handing out customer prefixes, not addresses.

Even if you delegate a prefix, you still need to know your customer's
address so that you might route packets to them.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
-- 
David W. Hankins        "If you don't do it right the first time,
Software Engineer                    you'll just have to do it again."
Internet Systems Consortium, Inc.               -- Jack T. Hankins

Attachment: pgpaVjhb83buJ.pgp
Description: PGP signature

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to