Subject: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-fqdn-00.txt

From: Jyrki Soini <[email-masked]>
Date: Fri, 17 Dec 2004 11:12:48 +0200

I have some questions and comments on draft-ietf-dhc-dhcpv6-fqdn-00.txt:

Introduction needs a paragraph stating that this option is only usable
with stateful dhcpv6 and reasoning behind the fact: e.g. dhcp server 
needs to maintain state per client for instance to remove stale dns RRs.
However, I suspect stateful DHCPv6 will not be the mechanism used to
assign addresses for hosts but stateless autoconfiguration will be used
instead. Perhaphs introduction could describe how the mechanism can
be used in that scenario?

Section 4.1 needs to be rewritten. At least I had to read it three
times to understand the usage of flag bits, that after all is not
that complicated.

Section 4.2: "Eventually, the IETF IDN Working Group is expected.."
IDN wg has since concluded. Anyhow, shouldn't option have domain-name
encoding in accordance with rfc3315 section 8 i.e. rfc1035 section 3.1?
--
Jyrki Soini
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 17 Dec 2004 10:14:31 -0500

Urgh!

As Olafur gave me plenty of good comments on the DHCPv4 Client FQDN option,
most of these apply to the DHCPv6 version and I should have requested that
Ralph not start the WG Last-Call on the DHCPv6 draft as well.

So, let's consider the WG Last Call stopped and once I get the DHCPv4 Client
FQDN option draft revised, I'll apply similar edits to the DHCPv6 one and
re-submit it as well.

Here's what I'm proposing for the revised DHCPv4 Client FQDN option
regarding the Flags bits. This, except for the "E" bit and DHCPv4 message
names, would be used for the DHCPv6 option. Let me know if you think this is
better.

4.1  The Flags Field

   The Format of the Flags Field is:

        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |  MBZ  |N|E|O|S|
       +-+-+-+-+-+-+-+-+

   When a DHCP client sends the Client FQDN option in its DHCPDISCOVER
   and/or DHCPREQUEST messages, the client:

   o  Sets (to 1) the "S" bit if it does not desire to perform any DNS
      updates and desires the DHCP server to perform FQDN to IP (the A
      RR) DNS updates on it behalf.  If the "S" bit is clear, the client
      indicates that it intends to maintain its own FQDN to IP mapping
      update.
   o  Clears (sets to 0) the "O" bit.  The "O" bit is only meaningful in
      Client FQDN options received from a server.
   o  Sets the "E" bit to indicate that the Domain Name field is in
      DNS-style binary encoding, without compression, as described in
      RFC 1035 [3].  A client which sends the Client FQDN option SHOULD
      use this encoding.  Server implementers SHOULD note that earlier
      draft versions of this specification permitted an ASCII encoding
      of the domain name and this encoding MUST be used if the "E" bit
      is clear.  Clients which implemented this encoding were deployed
      before this specification was completed.  Server implementers
      which need to support these clients need to see the section on the
      deprecated ASCII encoding (Section 4.3.1).
   o  Clears the "N" bit unless the client desires the server not to
      perform any DNS updates on its behalf.

   When a DHCP client receives the Client FQDN option in a DHCPOFFER
   and/or DHCPACK message:

   o  If the "S" bit is set, the server has taken responsibility for the
      A RR updates and the client SHOULD NOT perform these DNS updates.
      If the "S" bit is clear, the client MAY perform the A RR updates.
   o  If the "O" bit is set, the server has overridden the client's
      request for the server not to update the A RR.  The "O" bit MUST
      only be set if the "S" bit is also set.
   o  The "E" bit indicates the encoding of the Domain Name field, and
      the bit MUST match what the client sent.
   o  If the "N" bit is set and the client had set the "N" bit in what
      it sent to the server, the client SHOULD assume the server honored
      the client's request and will not perform any DNS updates.  If a
      client has set the "N" bit but its server does not, the client
      SHOULD conclude that the server was not configured to honor the
      client's request and that the server MAY attempt to perform DNS
      updates on the client's behalf.

   The remaining bits in the Flags field are reserved for future
   assignment.  DHCP clients and servers which send the Client FQDN
   option MUST clear the MBZ bits, and they MUST ignore these bits.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Jyrki Soini
> Sent: Friday, December 17, 2004 4:13 AM
> To: [email-masked]; [email-masked]
> Subject: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-fqdn-00.txt
> 
> 
> Introduction needs a paragraph stating that this option is 
> only usable with stateful dhcpv6 and reasoning behind the 
> fact: e.g. dhcp server 
> needs to maintain state per client for instance to remove 
> stale dns RRs. However, I suspect stateful DHCPv6 will not be 
> the mechanism used to assign addresses for hosts but 
> stateless autoconfiguration will be used instead. Perhaphs 
> introduction could describe how the mechanism can be used in 
> that scenario?
> 
> Section 4.1 needs to be rewritten. At least I had to read it 
> three times to understand the usage of flag bits, that after 
> all is not that complicated.
> 
> Section 4.2: "Eventually, the IETF IDN Working Group is 
> expected.." IDN wg has since concluded. Anyhow, shouldn't 
> option have domain-name encoding in accordance with rfc3315 
> section 8 i.e. rfc1035 section 3.1?
> --
> Jyrki Soini
>

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 17 Dec 2004 10:21:36 -0500

Oh, the encoding is the same. I just thought it easier to reference the
source rather than having to go through two RFCs (3315 -> 1035). But I'll
just reference RFC 3315 instead.

The IDN issue is already in the list of issues Olafur provided. Please see
my email titled "RE: [dhcwg] draft-ietf-dhc-fqdn-option to WG last call" on
12/14 to the DHC WG mailing list that listed Olafur's comments. Consider the
bulk of these to apply to the DHCPv6 Client FQDN option as well.

I'm also moving the DHCPv6 Client FQDN option to the Client message (ie,
removing it from being encapsulated in the IA_NA option). This should
simplify processing. If a client wants to use different names with different
bindings, it can just issue separate transactions (rather than putting
multiple bindings in a single transaction). Note that it is of course up the
server as to whether it allows multiple names or not in this case.

- Bernie

---

From: Jyrki Soini <[email-masked]>
Date: Fri, 17 Dec 2004 19:41:58 +0200

>    The Format of the Flags Field is:

I would remove "does not desire to perform any DNS updates and", that 
would make the sentence clearer.

s/it behalf/its behalf/

>       Client FQDN options received from a server.

o  Always clears...?

>       perform any DNS updates on its behalf.

How about:
o Clears the "N" bit if the client desires the server perform DNS 
updates on its behalf.

>    option MUST clear the MBZ bits, and they MUST ignore these bits.

Yes, this is better than before.

Still I wonder if there is reason why O bit tells that server has 
overriden client S bit setting, but N bit is handled differently?
Could flag semantics be:
S=0 client updates or does not want FQDN update at all, S=1 Server 
updates FQDN
O=0 server did as client requested, O=1 server did override request
N=0 client does PTR update or does not want it to be updated,
N=1 server updates PTR
E=1 use domain binary encoding, E=0 use deprecated ascii encoding
--
Jyrki
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 17 Dec 2004 13:18:04 -0500

Comments below, prefixed by BV>.

- Bernie

> From: Jyrki Soini [mailto:[email-masked]] 
> Sent: Friday, December 17, 2004 12:42 PM
> To: Bernie Volz
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-fqdn-00.txt
> 
> 
> Bernie Volz wrote:
> > Urgh!
> > 
> > As Olafur gave me plenty of good comments on the DHCPv4 Client FQDN 
> > option, most of these apply to the DHCPv6 version and I should have 
> > requested that Ralph not start the WG Last-Call on the 
> DHCPv6 draft as 
> > well.
> > 
> > So, let's consider the WG Last Call stopped and once I get 
> the DHCPv4 
> > Client FQDN option draft revised, I'll apply similar edits to the 
> > DHCPv6 one and re-submit it as well.
> > 
> > regarding the Flags bits. This, except for the "E" bit and DHCPv4 
> > message names, would be used for the DHCPv6 option. Let me 
> know if you 
> > think this is better.
> > 
> > 4.1  The Flags Field
> > 

BV> OK.

> >       Client FQDN options received from a server.

BV> OK.

> o Clears the "N" bit if the client desires the server perform DNS 

BV> Perhaps best to say "Sets the "N" bit if the client desires that the
BV> server perform no DNS updates on its behalf. If the "N" bit is set,
BV> the "S" bit MUST be cleared."

> overriden client S bit setting, but N bit is handled 
> differently? Could flag semantics be: S=0 client updates or 
> does not want FQDN update at all, S=1 Server 
> updates FQDN
> O=0 server did as client requested, O=1 server did override 
> request N=0 client does PTR update or does not want it to be 
> updated, N=1 server updates PTR E=1 use domain binary 
> encoding, E=0 use deprecated ascii encoding

BV> We'll have to see if anyone else comments. The initial design of the
FQDN
BV> option predates my work on this so I don't have the historical context
to
BV> answer this. Also, as this option is in wide use already, we need to be
BV> careful that we're not changing things! I believe the "N" bit overrides
BV> the "S" - in the client/server processing logic which has also been
BV> significantly revised, this is hopefully clear (N bit is processed
first).

BV> I should be submitting the revised draft next week.

---

From: Robert Elz <[email-masked]>
Date: Sat, 18 Dec 2004 23:30:26 +0700

Date:        Fri, 17 Dec 2004 10:14:31 -0500
    From:        "Bernie Volz" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Here's what I'm proposing for the revised DHCPv4 Client FQDN option
  | regarding the Flags bits.

Is there any chance of having this written in a form so that the text
simply says what the flag bits mean, rather that saying when the server
or client set or clear the things?

Personally, I find that I have no trouble working out when I am supposed
to set and clear bits to get the effect I'm after if I know what things
mean, but I find it annoying to have to reverse engineer someone's thinking
process to work out what something means from the circumstances in which
something or other would or would not, be done.

So, for example, rather than (the combination of)

	[The client] Sets (to 1) the "S" bit if it does not desire to perform
	any DNS updates and desires the DHCP server to perform FQDN to IP
	(the A RR) DNS updates on it behalf.  If the "S" bit is clear, the
	client indicates that it intends to maintain its own FQDN to IP
	mapping update.
and
	[When received by the client] If the "S" bit is set, the server has
	taken responsibility for the A RR updates and the client SHOULD NOT
	perform these DNS updates.  If the "S" bit is clear, the client MAY
	perform the A RR updates.

I'd say something more like

	S bit:  Set to 0 indicates that the client is responsible for
		any desired DNS update of the FQDN to address mapping.
		Set to 1 indicates that the server is responsible for
		updating the mapping.   The client sets this bit to
		indicate its preference, the state of the bit in a reply
		from the server indicates the action taken by the server.

I also (personal preference) dropped the SHOULD NOT about the client doing
its own updates - whether or not the client can/should update the DNS
itself is a matter for arrangement between the client and the DNS servers.
What the DHCP server tells me about this isn't likely to have much impact
on what my client attempts to do (though if I have no specific knowledge of
the domain, or its servers, I'd probably follow the DHCP server's sueggstion,
but I'd do that by setting S=1, and then observing the state of the bit in the
reply.   I actually see no reason to allow the server to override the S=0
state from the client (though of course the server isn't required to handle
S=1 from the client).

I also see no reason for the O bit, if the clint set S=0, and the reply
comes back with S=1, (which is the only time O=1 is appropriate, from what
I can see) it is pretty obvious already what happened - or is this some kind
of attempt to prevent the client from needing to keep state?   That would
be fairly pointless wouldn't it?

kre

---

From: Jyrki Soini <[email-masked]>
Date: Mon, 20 Dec 2004 16:23:09 +0200

> 		from the server indicates the action taken by the server.

This would make flag semantics clearer, I agree.

> be fairly pointless wouldn't it?

Well, we might want to keep all flags N,E,O,S for IPv4 version for 
backwards compatibility reasons.

As far as I know, there is no (at least large intalled base) DHCPv6 FQDN 
option implementation, and we could perhaps use only two flag bits and
even name them differently. How about having:
Client sets flag:
A = 0, asks DHCPv6 server not to modify AAAA record for FQDN
     1, asks DHCPv6 server to modify AAAA record for FQDN
P = 0, asks DHCPv6 server not to modify PTR record for FQDN
     1, asks DHCPv6 server to modify PTR record for FQDN
Server indicates action:
A = 0, DHCPv6 server did not/won't modify AAAA record for FQDN
     1, DHCPv6 server did/will modify AAAA record for FQDN
P = 0, DHCPv6 server didn't/won't modify PTR record for FQDN
     1, DHCPv6 server did/will modify PTR record for FQDN
--
Jyrki
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Jyrki Soini <[email-masked]>
Date: Mon, 20 Dec 2004 16:50:37 +0200

> server as to whether it allows multiple names or not in this case.

I'm afraid this is not a good idea. There is a clear need to bind FQDN
to IPv6 address. OPTION_IAADDR is IA_NA/IA_TA option and if we move FQDN
option to the Client message, we need to add IPv6 address(es) to FQDN 
option or create OPTION_IAADDR equivalent new Client option.

Which reminds me that we should have some option order rules written 
down. E.g. OPTION_IAADDR option(s) is(/are) associated with the FQDN 
option(s) that follow them. Or vise versa?
--
Jyrki
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Robert Elz <[email-masked]>
Date: Mon, 20 Dec 2004 22:05:37 +0700

In a message on another thread ...

    Date:        Mon, 20 Dec 2004 16:23:09 +0200
    From:        Jyrki Soini <[email-masked]>
    Message-ID:  <[email-masked]>

  | As far as I know, there is no (at least large intalled base) DHCPv6 FQDN 
  | option implementation,

which reminded me to ask something I have been wondering about for
a while.

I know there are available DHCPv6 (at least DHCPv6Lite) implementations
(servers) around, but are there any functional DHCPv6 clients available
yet?

And here I mean real clients, ones that actually configure a system,
I'm not interested in test/debug code that sends messages, receives
replies, and tells the user what happened (as useful as such things
are for server testing).

That is, which (if any) systems currently react correctly to the M and O
flags in IPv6 RA messages, and perform the appropriate configuration
(or attempt to) ?

kre

---

From: "Bernie Volz" <[email-masked]>
Date: Mon, 20 Dec 2004 10:43:41 -0500

Hi:

I don't follow what you're driving at?

Do you have specific cases where a client needs a unique name associated
with each address that may be in an IA_NA. (IA_TA's are not likely to have
domain names, so I personally would suggest we ignore those?)

I used to think we needed a more complex mechanism, but I've not figured out
where this would be used and how this would work.

In the client to server communication, we really have no easy means to
associate a name with a specific address or a specific prefix.

The server might have different configurations for different prefixes. In
this case, though, think about who is doing what updates. The server is
doing the PTR updates and those are the ones that are likely to go to
different zones. The client MAY be doing the AAAA updates, but do you really
want to give the client multiple names and for what purpose?

We are trying to target this option at the most general and typical cases
and trying to get this off the ground. We can always expand/amend the
functionality in the future to address more complex environments.

Having a client FQDN option at the "outer-most scope" will likely be
sufficient for 99% of the cases.

- Bernie

> Sent: Monday, December 20, 2004 9:51 AM
> To: Bernie Volz
> Cc: [email-masked]
> > I'm also moving the DHCPv6 Client FQDN option to the Client message 
> > (ie, removing it from being encapsulated in the IA_NA option). This 
> > should simplify processing. If a client wants to use 
> different names 
> > with different bindings, it can just issue separate transactions 
> > (rather than putting multiple bindings in a single 
> transaction). Note 
> > that it is of course up the server as to whether it allows multiple 
> > names or not in this case.
> > 
> > - Bernie
> 
> I'm afraid this is not a good idea. There is a clear need to 
> bind FQDN to IPv6 address. OPTION_IAADDR is IA_NA/IA_TA 
> option and if we move FQDN option to the Client message, we 
> need to add IPv6 address(es) to FQDN

---

From: "Bernie Volz" <[email-masked]>
Date: Mon, 20 Dec 2004 12:15:16 -0500

There is dibbler which seems to configure the system.

See http://klub.com.pl/dhcpv6/.

> On Behalf Of Robert Elz
> Sent: Monday, December 20, 2004 10:06 AM
> To: [email-masked]
> Subject: [dhcwg] DHCPv6 clients
> 
> 
> which reminded me to ask something I have been wondering 
> about for a while.
> 
> (servers) around, but are there any functional DHCPv6 clients 
> available yet?
> 
> And here I mean real clients, ones that actually configure a 
> system, I'm not interested in test/debug code that sends 
> messages, receives replies, and tells the user what happened 
> (as useful as such things are for server testing).
> 
> That is, which (if any) systems currently react correctly to 
> the M and O flags in IPv6 RA messages, and perform the 
> appropriate configuration (or attempt to) ?
> 
> kre
> 
>

---

From: Jyrki Soini <[email-masked]>
Date: Tue, 21 Dec 2004 11:11:57 +0200

> domain names, so I personally would suggest we ignore those?)
IA_TA's don't need FQDN option.

> want to give the client multiple names and for what purpose?
This is quite marginal case, but could use the mechanism.
Say the dhcp client is a server that provides services for several 
organizations and belong to each organization domain. For some reason 
server needs different address to serve each organization. For instance 
such reason may relate to firewall policies. The addresses may be 
configured statically, but PTR update for domain is done with dhcpv6 
server assistance.

Client creates a request message
IA_NA
   OPTION_IAADDR 2001:bd8:1:1::1
   FQDN a.sample.org
   OPTION_IAADDR 2001:db8:2:2::2
   FQDN e.xample.org
   option IAADDR 2001:db8:3:3::3
   option IAADDR 2001:db8:4:4::4
   FQDN server.anydomain.net

> functionality in the future to address more complex environments.
The above example is corner case, I agree.

> sufficient for 99% of the cases.
Here I have some doubt. I think stateless autoconfiguration will still
be used for address generation for most cases and stateful configuration 
with dhcpv6 will remain minor. DDNS updates with dhcpv6 server have 
operational advantages still. If stateless autoconfiguration or manual 
address configuration is used dhcpv6 server doesn't have existing 
information about client IPv6 addresses. It is possible to
provide the addressing information from client if IA_NA option 
OPTION_IAAADR is used in concert with FQDN option. If FQDN option is
moved to client option this possibility is missed. Or am I missing 
something?

Jyrki

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Dec 2004 08:08:45 -0700

On Dec 21, 2004, at 2:11 AM, Jyrki Soini wrote:
> server needs different address to serve each organization. For 
> instance such reason may relate to firewall policies. The addresses 
> may be configured statically, but PTR update for domain is done with 
> dhcpv6 server assistance.

In this case I think it would make the most sense to configure the 
device to update the DNS itself.   Adding a great deal of complexity in 
order to address corner cases seems like a bad idea.   Furthermore, as 
Bernie pointed out in a previous message, you can always get the 
different IP addresses in different DHCP messages if you want to send 
different FQDN options, so you aren't _prevented_ from doing this.

Anyway, the bottom line is that we talked about this, and were quite 
skeptical that this would actually occur in the real world.   We want 
to see an actual example of the problem in the real world.   Otherwise 
we're adding something to the protocol to address a problem that we 
imagine might happen, where we aren't particularly sure *how* it will 
happen.   Since this isn't a security issue, it doesn't need to be 
dealt with in advance in order to prevent a catastrophe, so there's no 
urgency in resolving the problem.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 21 Dec 2004 19:30:06 -0500

kre - There is a DHCPv6 client in IOS that does configuration of DNS 
servers, etc., and prefix delegation (but not address assignment).  It does 
react correctly to the state of the 'O' flag.

- Ralph