[dhcwg] I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt

Ted:

At the San Diego DHC WG meeting, you asked whether the complexity of the
proposed DHCPv6 client FQDN option is needed?

I started out wanting to keep this simple by having ONE client FQDN option
per IA_* option, not one per address (IAADDR option). However, in some
preliminary reviews, Ralph commented that this may not be appropriate for
all situations.

There are four situations in particular that are important to consider,
though the first two are dependent on how clients are likely to request
addresses:

1. Suppose a DHCPv6 client is running a multi-homed web server. When that
client requests addresses, for IA_NA IAID=1 for example, the DHCPv6 server
may be configured to provide it n global unicast addresses for the different
web sites. Each of these addresses is likely to be associated with a
different name. Obviously, the server would also need to be configured for
the DNS name for each of the addresses (and otherwise ignore the clients
suggested name, at least on the configured addresses).

2. Suppose a DHCPv6 client requests temporary addresses for IA_TA IAID=1 and
also suggests a name for these temporary addresses. The server is configured
to assign 3 temporary addresses and a different name should, ideally, be
used for each (since using the same name negates much of the privacy since
the linkage between the names is now in DNS).

Note on 1 and 2: In the DHCPv6 specification, we aren't extremely clear as
to what the bounds of an IAID are. For example, should the client really be
requesting multiple IA_NAs and IA_TAs instead of a single of each? If we
were to say yes, how does the client know how many to request? Perhaps this
is where a Client API would come in useful - since the web server in case 1
and the applications that want a privacy address in case 2 should request
the information they need when they need it? And, if there are in separate
IA_*'s, then the unique name for each isn't an issue.

3. Suppose a site is multi-homed and wants to have different names
associated with each of the global addresses? This is harder to see as if
I'm at Cisco and there are 3 different ISPs that connect me to the internet,
my system is likely to have ONE "cisco.com" name - not three. But, perhaps
there is a reason to have <host>.isp1.cisco.com, <host>.isp2.cisco.com,
<host>.isp3.cisco.com?

4. I saved the most likely for last ... Suppose a client is allocated both
global unicast and unique local unicast addresses. The domain names for
these are likely to be different as unique local unicast addresses shouldn't
appear in the global DNS? (Same applies to the to be deprecated site-local
addresses - they too would not be in the same DNS name space.)

Perhaps this last case is an argument for considering an IA_UL (unique
local, or IA_SL for site-local) option?

The current Client FQDN draft would accommodate any of the above, whereas
the simpler model would not.

Your comments are always welcome and it would be nice to resolve this issue
soon. I'd like to publish an updated draft (as a DHC WG work item).

- Bernie

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg