RE: [dhcwg] additional option for dhcpv6

["Vijayabhaskar A K" <[e-mail]>]

RE: [dhcwg] additional option for dhcpv6Bernie,
I didn't talked anything about DDNS updates for temporary addresses. What i
have defined is similar one like "hostname" option (option 12) in  DHCPv4.
It has the same functionality as option 12 in DHCPv4. If there is any FQDN
related to address assigned, i wanted an option that informs the FQDN to
client. This can be used for transfering hostnames/FQDN from client to
server and vise versa. This holds for both normal addresses and temp
addresses also. It is just a "hostname" option not an FQDN option.

Since, DDNS updates is still TBD, i don't know, what are the fields needed
for FQDN option. Let us decide whether the client or server is doing dns
updates. Then based on that,we can decide the fields on FQDN option. I feel
that if we are strictly moving some part or complete dns updates to client,
we don't need one or both of the RCODE*.  Do correct me, if i am wrong.

Vijay:
  I don't understand your desire to do DDNS updates for temporary addresses.
We specifically do NOT want to do them. The -22 draft just says that if a
server does DDNS updates, it must follow the rules of RFC 3041.

  I think you have things backwards a bit. Non-temporary addresses are the
addresses that need domain names (FQDNs) assoicated with them. Temporary
addresses really shouldn't since that defeats the purpose of temporary
addresses. However, what RFC 3041 says, is that if DDNS updates are done,
the name should be something that doesn't identify the client. It gives one
reason for doing this and that is to keep applications happy that
"authenticate" clients by doing a reverse and then forward lookup to assure
the client is in DNS.

   We need a general FQDN option. Where it is placed (encapulated within the
option area of an IA Address option, inside the option area of an IA option,
or outside IA options) determines its scope (to one address, several
addresses, or all addresses). For temporary addresses, the scope should be
to that one address (since even using the same name with two temporary
addresses could leak information about the client).
  So, I see no value in an option that is just for temporary addresses. We
should define a FQDN option and use it whenever DDNS updates are done. The
format should be defined as in draft-ietf-dhc-fqdn-option-03.txt with the
following differences:

  - a 16-bit option number/option length
  - "A" RRs replaced by "AAAA" RRs.
  - Name encoding should be as per section 10 of the -22 draft on DNS
encodings (hence we technically don't need the "E" bit in the flag field but
I would recommend we simply specify it MUST always be set to allow common
code to be used on the client and/or server).