Subject: [dhcwg] way forward for the mipshop-mos-dhcp document

From: Jari Arkko <[email-masked]>
Date: Mon, 09 Mar 2009 22:56:42 +0200

Hi all,

There's a new version. This version completely removes the problems we 
had with the variable encoding.

The version does keep the ability to provide both addresses and FQDNs 
for the mobility servers, however, using separate options. I personally 
think this issue was far less pressing than the above one; if servers 
can't deal with the encoding that's a serious deployment barrier. If 
there's multiple formats to deliver information, that is an extra 
implementation burden and a potential interoperability issue for nodes 
that choose to disobey the RFC and not implement both. However, folks 
who want to deploy this could overcome these easily. As a result, I'm 
fine with the document moving forward as it is. However, the two WGs 
need to be OK with them as well, and when we talked about this in DHC 
there were concerns about providing both addresses and FQDNs. Can we try 
to close that issue and move on?

In my mind the question is whether the two formats are justified. I have 
been thinking about this today and I can see an excellent argument for 
why FQDNs need to be supported. There are some, but not quite as 
convincing arguments for why addresses need to be supported.

The FQDNs need to be supported because DHCP simply delivers information 
about the server, but has no understanding of further details. For 
instance, 802.21 mobility servers may operate using multiple transport 
protocols (UDP, TCP, maybe SCTP). There are SRV record mechanisms in 
place to discover what transport protocols are available and at which 
port they run on. However, the transport protocol information is not 
carried in DHCP (nor would it make sense to do so). And it does not help 
if the DHCP server resolves some of these queries, because IMHO it would 
not make sense for the DHCP server to be aware of all the details of 
client capabilities. As a result, it seems that if we want to enable 
dynamic negotiation of transport protocols or ports, you have to support 
FQDNs.

The arguments for the pure address delivery are that (1) its the common 
way to deliver information in DHCP, so it could be supported as a "base" 
mechanism for networks that do not need any SRV mechanisms and (2) there 
may be networks that do not have DNS names for all entities.

I personally think these reasons are sufficient to let the documents 
move forward (or to be more exact, insufficient for us to block the 
802.21 folks from introducing additional complexity if they really 
insist on it). I do acknowledge that the arguments for pure address 
delivery are on the weak side. But what does the DHC WG think? Is the 
above analysis correct? Are there other means to do this that I missed?

Jari

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 9 Mar 2009 19:46:33 -0400

I'm OK with this.

There are some other issues with the
draft-ietf-mipshop-mos-dhcp-options-11.txt draft though that I found in
a quick review:

Section 3:

   The Sub-option begins with a sub-option code followed by a length 
   and a sequence of labels that are encoded according to Section 8 of 
   [RFC3315]. 
  
   [RFC1035] encoding was chosen to accommodate future international-
   lized domain name mechanisms. The minimum length for this encoding 
   is 3.  

I don't understand why the minimum length of RFC 1035 encoding is 3? If
you wanted to send "." it would be 1 octet (or a. which would be 2).
Perhaps "this encoding" refers to the suboption/suboption-length/data
but it is not clear in this text. Also, the switch between RFC 3315 to
RFC 1035 is a bit odd unless one actually looks at RFC 3315, Section 8.

In secton 6.1.1 (and 6.1.2), both DHCPDISCOVER and DHCPREQUEST (and
DHCPOFFER and DHCPACK) should contain these options. The DHCPACK is what
gives the client the 'final' configuration.

Also, later in section 6.1.2 and 6.2.2:

   In case that the server cannot find any Mobility Server satisfying 
   the requested Sub-opt Code, the server MUST return the MoS Option 
   with a sub-option by setting the Sub-opt Code to the requested
   Sub-opt Code and the length of the sub-option to 1.

I could understand this if the sub-option length was 0, but 1? If 1,
what should the data byte contain?

Also, as this client/server behavior requires SPECIAL processing in the
server, I suspect adoption will be slow. You really should simplify this
to allow the client to request those that it wants and the server to
optionally use that in what it returns, but the server could just return
a static list and the client needs to match them up? Of course, if
there's more than just sending back these options that the server needs
to do, perhaps it is OK to require the complexity but again uptake will
be slow.

For DHCPv6, don't you want to allow these for RENEW or REBIND messages
as well? And, probably they should be allowed in a SOLICIT as then the
server can tell the client what it would give it later?

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jari Arkko
Sent: Monday, March 09, 2009 4:57 PM
To: Dhcwg; [email-masked]; Mipshop
Chairs
Subject: [dhcwg] way forward for the mipshop-mos-dhcp document

Hi all,

FQDNs.

Jari

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 10 Mar 2009 07:24:38 +0200

Thanks for your review. Authors, please take care of the issues from Bernie.

Jari

---

From: Subir Das <[email-masked]>
Date: Wed, 11 Mar 2009 12:15:10 -0400

Bernie,
Thanks for your review and comments. We will address them.

-Subir

---

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Mar 2009 02:07:11 +0200

Are there others than Bernie who want to comment on the high level 
design here? I'd like to move forward with the draft (after letting the 
authors fix the more detailed problems, of course).

Jari

Jari Arkko wrote:
> for the mobility servers, however, using separate options. I 
> personally think this issue was far less pressing than the above one; 
> if servers can't deal with the encoding that's a serious deployment 
> barrier. If there's multiple formats to deliver information, that is 
> an extra implementation burden and a potential interoperability issue 
> for nodes that choose to disobey the RFC and not implement both. 
> However, folks who want to deploy this could overcome these easily. As 
> a result, I'm fine with the document moving forward as it is. However, 
> the two WGs need to be OK with them as well, and when we talked about 
> this in DHC there were concerns about providing both addresses and 
> FQDNs. Can we try to close that issue and move on?
>
> In my mind the question is whether the two formats are justified. I 
> have been thinking about this today and I can see an excellent 
> argument for why FQDNs need to be supported. There are some, but not 
> quite as convincing arguments for why addresses need to be supported.
>
> The FQDNs need to be supported because DHCP simply delivers 
> information about the server, but has no understanding of further 
> details. For instance, 802.21 mobility servers may operate using 
> multiple transport protocols (UDP, TCP, maybe SCTP). There are SRV 
> record mechanisms in place to discover what transport protocols are 
> available and at which port they run on. However, the transport 
> protocol information is not carried in DHCP (nor would it make sense 
> to do so). And it does not help if the DHCP server resolves some of 
> these queries, because IMHO it would not make sense for the DHCP 
> server to be aware of all the details of client capabilities. As a 
> result, it seems that if we want to enable dynamic negotiation of 
> transport protocols or ports, you have to support FQDNs.
>
> The arguments for the pure address delivery are that (1) its the 
> common way to deliver information in DHCP, so it could be supported as 
> a "base" mechanism for networks that do not need any SRV mechanisms 
> and (2) there may be networks that do not have DNS names for all 
> entities.
>

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 16 Mar 2009 15:14:53 -0700

Sorry if this overlaps Bernie's response, I can't remember what he
said now.

On Mon, Mar 16, 2009 at 02:07:11AM +0200, Jari Arkko wrote:
>> The version does keep the ability to provide both addresses and FQDNs for 
>> the mobility servers, however, using separate options. I personally think 
>> this issue was far less pressing than the above one; if servers can't deal 
>> with the encoding that's a serious deployment barrier. If there's multiple 
>> formats to deliver information, that is an extra implementation burden and 
>> a potential interoperability issue for nodes that choose to disobey the 
>> RFC and not implement both. However, folks who want to deploy this could 
>> overcome these easily. As a result, I'm fine with the document moving 
>> forward as it is. However, the two WGs need to be OK with them as well, 
>> and when we talked about this in DHC there were concerns about providing 
>> both addresses and FQDNs. Can we try to close that issue and move on?

One question is which of the two options should the client accept if
it receives both?  Consider that a simplistic client might attempt to
configure both, as though it had two servers.  Unless the protocol
has a way to detect they're talking to the same device mulitiple
times, there might be unintended consequences.

So it would be my suggestion based upon this feedback, that only the
FQDN-formatted option should be selected, because the address-
formatted option becomes seemingly superfluous.

>> may be networks that do not have DNS names for all entities.

The other motivation for raw-address format options I've encoded in my
draft is that it reduces the number of packets it takes to finalize
the client's configuration (important when you spend battery power to
transmit), also reducing the number of 'moving parts' to configure the
client...only the DHCP service needs to respond, the DNS service can
be overloaded or down.

It is my personal advocation to choose raw formats because as a once-
operator I know what configuration the client should have at the time
I write my dhcpd.conf, and it is "making a mountain out of a molehill"
to introduce other mechanisms after DHCP - said another way, if I
cannot express a precise, final configuration for the client at DHCP-
time, my time as an operator is being wasted.

But, I seem to recall that the FQDN->SRV mechanism solves a cross-
administrative-domain problem for them, so I think that should be the
way to go.

I also won't object to two options, but I have a suspicion one will be
deprecated over time.

>> weak side. But what does the DHC WG think? Is the above analysis correct? 
>> Are there other means to do this that I missed?

I think the main points of deploy/usability are solved, so it's OK to
proceed.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins