RE: [dhcwg] additional option for dhcpv6

[Jim Bound <[e-mail]>]

whoops meant DDNS not DDSN below.
.jim


/jim


On Sun, 20 Jan 2002, Jim Bound wrote:

> 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
> 
> 
> On Sun, 20 Jan 2002, Bernie Volz (EUD) wrote:
> 
> > 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:[e-mail]]
> > Sent: Sunday, January 20, 2002 9:34 AM
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail]
> > 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> > 
> 
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 


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