Subject: RE: [dhcwg] additional option for dhcpv6

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Sun, 20 Jan 2002 11:57:08 -0600

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).

- Bernie

-----Original Message-----
From: Vijay Bhaskar A K [mailto:[email-masked]]
Sent: Sunday, January 20, 2002 9:34 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [dhcwg] additional option for dhcpv6

Mark,

Thanks for your thorough review. See my comments inline.

~ Vijay

> 1) The FQDN option needs, I think, to look a lot like the FQDN option for 
> dhcpv4. 

The option i defined here is, for just  transfering the FQDN releated to
temporary  address.  It is  similar  to  hostname  option in  DHCPv4.  I
will rename it to hostname  option.  I feel like, since the DDNS updates
are still TBD, we can define the FQDN  option  with  appropriate  fields
needed later, once DDNS specs are finalised.

> The name encoding must be specified. 

Yes. It is needed. I will add the appropriate text.

> There needs to be 
> specification about hosts who do not initially know their entire fqdn.
> There needs to be a way to communicate about which party (if any) will be 
> updating DNS. It's probably on my plate to produce that, actually.

For the  temporary  addresses,  DNS update is done by server.  So, these
fields are not necessary.

> 
> 2) The subnet-selection option text should not compel the server to somehow 
> obey the client's suggestion. It should be explict that the server 
> administrator's configuration takes precedence, and that the client's 
> indication that it desires a specific subnet can only be a hint that's 
> considered along with all of the other information available to the server.

This is the only way the client can tell its  prefernce  for the prefix.
If the server is not supposed to allocate  address for that prefix, then
it wont.  If the  client is not very  particular  about the  prefix,  it
should not use this  option.  This  option  will be more  helpful in the
network with two prefixes and the client wants a particular one.

> 
> A nit: isn't the option-len sufficient to determine the prefix length? Is 
> the prefix-len byte necessary?

No, it is not sufficient.  Without the prefix-len field, you cannot find
out the exact prefix length.  For example, you can identify  whether the
prefix  length  is  between  57 and 64.  You  cannot  find out the exact
prefix length.

> 
> 3) The encoding for the domain names in the NIS and NIS+ Domain Name 
> options should be DNS encoding, shouldn't it? That seems more robust than 
> ASCII to me.

Agreed.

> 
> 4) The 'Service Location Protocol Directory Agent Option' places the 
> 'typed-scope-list-len' field before the 'DA address', rather than before 
> the 'typed scope list'. Couldn't the length of the list immediately precede 
> the list?

I think,  it won't  make any  difference.  Let me  know, if there are any
serious issues on this.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Mon, 21 Jan 2002 00:25:57 +0530

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).

---

From: Jim Bound <[email-masked]>
Date: Sun, 20 Jan 2002 20:20:12 -0500 (EST)

Folks,

I have mixed feelings.  I see Vijay's point but I also agree with Bernie.
I suggest we not in DHC6 try to resolve the rules for DDNS and just make
sure we have mechanism to permit DHC6 process FQDN's.   Temp addr RFC
3041, DDSN, and FQDN DHC specs define the rules and interoperability
issues.  I suggest we not try to do that in DHC6.

/jim

---

From: Jim Bound <[email-masked]>
Date: Sun, 20 Jan 2002 20:41:01 -0500 (EST)

whoops meant DDNS not DDSN below.
.jim

/jim

On Sun, 20 Jan 2002, Jim Bound wrote:

> > Agreed..