Subject: RE: [dhcwg] additional option for dhcpv6

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Sat, 19 Jan 2002 08:53:20 -0600

I haven't looked in detail at Vijay's option definitions, but all domain names
should be encoded using Section 10 (Representation and use of domain names). So,
this may remove the need to have a bit in the FQDN option to specify the encoding!
This applies to issues 1 and 3 below.

- Bernie

-----Original Message-----
From: Mark Stapp [mailto:[email-masked]]
Sent: Friday, January 18, 2002 5:07 PM
To: Vijay Bhaskar A K
Cc: [email-masked]
Subject: Re: [dhcwg] additional option for dhcpv6

Vijay,
Thanks for putting this list together. I have a couple of observations.

1) The FQDN option needs, I think, to look a lot like the FQDN option for 
dhcpv4. The name encoding must be specified. 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.

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.

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

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.

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?

-- Mark

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

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 21 Jan 2002 01:37:39 -0600

My feeling is that we should follow the work being done in DHCPv4 in this area (FQDN) as defined by draft-ietf-dhc-fqdn-option-03.txt. Whether we also have a host name option is still TBD - I believe Carl Smith and Ted Lemon will be working up some text for DHCPv4 and it would be good to wait until we have some clear definitions around proper behavior and interactions between the host name, domain name, and FQDN options. Unless there are some significant reasons to defer from DHCPv4 options, I would recommend using the DHCPv4 options as closely as possible. We have a lot of experience with those options already!
 
- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:[email-masked]]
Sent: Sunday, January 20, 2002 1:56 PM
To: 'Bernie Volz (EUD)'; [email-masked]
Cc: [email-masked]; Vijayabhaskar A K (E-mail)
Subject: RE: [dhcwg] additional option for dhcpv6

Bernie,
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: Terrance Humphries <[email-masked]>
Date: Tue, 22 Jan 2002 08:41:14 -0700

Please remove me from your list.

Thanks,

Terrance Humphries
Network Security and 
Administration Manager
[email-masked]
801-224-7513

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Vijay Bhaskar A K
Sent: Sunday, January 20, 2002 7: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

> 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

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

> 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

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.

> options should be DNS encoding, shouldn't it? That seems more robust
than 

Agreed.

> the 'typed scope list'. Couldn't the length of the list immediately
precede 

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