Re: To address or NAT to address?

[Bill Fink <bill at wizard.nasa.atd.net>]

> Bill Fink wrote:
> 
> >         Now if we could only have an alternate stateful address
> > configuration method than the backwards one of DHCPv6, one that
> > generated an IPv6 address directly from the host's domain name
> > rather than from a layer 2 MAC address, we'd really be in business.
> > Maybe that too will come eventually.
> 
> DHCPv6 does allow the client to include its domain name as part of
> a DHCP Request, which a DHCP Server could use to identify the
> right address for the client on the originating network link.
> We expected that the domain name might be used for exactly this
> purpose.
> 
> Isn't this what you want?
> 
> Regards,
> Charlie P.

DHCP has its purposes, but it shouldn't be a required component
of an Internet system.  The routing and DNS systems should be
sufficient if properly designed.  The fewer systems you have to
manage and thus the smallest amount of interactions between those
systems provides the simplest, most manageable, and robust overall
system.  Anyone who has worked with ATM software knows that its
complexity and multiple interdependent systems has made it a
complete nightmare to manage and troubleshoot, and I would hate
to see that happen to IPv6 (although I'm sure that there are
some who would argue that it's already getting there).  I totally
believe in the KISS principle that Steve Deering adhered to in
the basic protocol design, and I think that the supporting network
infrastructure should be handled the same way.

I have never seen any documentation about how the dynamic updates
are supposed to be handled between the DHCPv6 and DNS systems,
although I haven't been following recent developments that closely,
so it's possible I may be behind the times (if so please point me
at the appropriate draft(s) to read and I'll gladly do so).  Without
this in place, I can't see how any large scale serious deployment
of IPv6 can go forward.

The way I believe stateful address configuration should work is
basically as follows.  The host should be configured with its
hostname, domain name, and possibly a security key.  It would
then multicast a DNS request with site local scope, providing
its hostname, domain name, subnet (from router advertisement),
and MAC address (and possibly the security key).  By the way,
this might be another use of site-local addresses, for the
source address in this request.  The DNS server would then
look up the hostname (validating the request using the security
key if present and a secure domain), construct an IPv6 address
out of the site prefix, subnet, and MAC address info (or optionally
could generate a random address in place of the MAC address), and
send that back to the host using its site-local address.  The host
would validate the reply (using the security key if present) and
would be in business.  The address lifetime values would need to
be added to the DNS info for the host's address, but that's where
they really belong anyway.

Routing system.  DNS.  That's it, all that's really necessary.
If you need additional info like a boot file name or such, that's
where I would see DHCP coming into play.  But for basic addressing
requirements, keep it all in the DNS.  It should make life much
simpler all around.

						-Bill