Subject: [dhcwg] Status of draft-ietf-mos-dhcp-options

From: Jari Arkko <[email-masked]>
Date: Tue, 13 Jan 2009 22:32:21 +0200

The new version of this draft addressed the issues that I found in my AD 
review. However, I'd like to have positive confirmation from the DHC WG 
that they are fine with the syntax. I can see that the bit pattern 
mechanism was simplified, but "enc" still remains, and I think David 
complained about that in particular. If existing DHCP server software 
cannot deal with a conditional encoding of attributes, I'd recommend 
simplifying further. You do NOT want to upgrade client and server code 
just to transport one additional piece of config data.

Jari

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

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 15 Jan 2009 15:53:33 -0800

On Tue, Jan 13, 2009 at 10:32:21PM +0200, Jari Arkko wrote:
> simplifying further. You do NOT want to upgrade client and server code just 
> to transport one additional piece of config data.

I've reviewed the changes in this draft.

This protocol as currently written is not adoptable by existing DHCPv4
software on the Internet.  To use this protocol, the administrator of
a DHCP server must become intimately familiar with the wire format,
and author the wire format directly in contrived and complicated
configuration syntax (often, hexadecimal).  Comfortable use of the
protocol, converting presentation input to wire format, will require
source code changes.

It is my opinion that you can expect to wait until at least 2016 with
fair winds (high user demand) before this protocol can reasonably be
used on the Internet.  Never at worst.

For most protocols, this is a "non-starter" adoption problem.

The core reason for my opinion as stated above is the 'enc' byte in
the sub-option syntax.  I strongly recommend that MIPSHOP come to
consensus on whether this configuration value can be configured by
IPv4 address on the wire (and FQDN in DHCP server config, resolved
on demand for clients as is done today), or if an FQDN is truly
mandatory, and choose only one of these two formats.

-- 
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
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Subir Das <[email-masked]>
Date: Thu, 15 Jan 2009 21:43:53 -0500

David,
Thanks for another review.  We can certainly go with your proposal but 
our understanding
is that there are existing RFCs  (e.g., RFC 3361, RFC 3495) that support 
similar 'enc' byte
and these options are adopted.

regards,
-Subir

---

From: Bud Millwood <[email-masked]>
Date: Fri, 16 Jan 2009 09:45:37 +0100

> protocol, converting presentation input to wire format, will require

David: I think the cat's out of the bag on this one. (We just bit the bullet 
and decided to support an 'encoding' field generically.)

Subir: There's probably no technical argument against this format, but David's 
point about the number of existing DHCPv4 servers that can natively handle 
the format is a good point. There are many existing installations that will 
have to resort to hex presentation.

My own feeling is that the 'encoding' field is a de-facto standard, and we 
should fully support it.

- Bud

-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 16 Jan 2009 09:38:15 -0800

On Thu, Jan 15, 2009 at 09:43:53PM -0500, Subir Das wrote:
> Thanks for another review.  We can certainly go with your proposal but our 
> understanding

I would not describe either option as well deployed.  It's my view
that both possess the same limitations I've warned against.

The only 'enc byte option' I'm immediately aware of that I'd describe
as well deployed today also requires other server-side special case
code (the processing of dynamic updates), and so must be written by
new machine language.  The demand for dynamic updates was sufficient
to cause the new code to start appearing in multiple DHCP software
suites relatively quickly (a mere few years).  Even in this case, the
approach used was to deprecate all but one encoding (although there
were only two).  The reason for the deprecated format's inclusion was
that implementations already existed.

I'm unconvinced the demand for these options is sufficient for good
deployment, and I haven't heard of existing implementations, so I am
not changing my guidance.  I think MIPSHOP should pick one encoding
and stick with it.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Jan 2009 10:24:41 -0800

> not changing my guidance.  I think MIPSHOP should pick one encoding

I have to side with David here.   I was very much against the encoding  
options in the other two RFCs as well, for two reasons:

1. As David says, it's extra code, which nobody is going to implement  
if they don't have to.
2. It's an additional knob to turn, and chances are that it will  
always be turned the same way.   And so the other way won't get tested  
(I wish it were not so, but client testing has historically been very,  
very spotty).   And then when someone does use it, it will break.   If  
there were some value being added, it would be one thing, but there's  
no value added here - it's just a decision the protocol designer is  
deciding not to make.

My advice is to make the decision, and make it the way everyone else  
does: send an IP address.   If you don't agree with this decision,  
please state a use case for the FQDN encoding.   Not "someone might  
want to do FQDN encoding for some reason" but rather "in this case  
(provide a case here) it will be necessary to do FQDN encoding because  
IP-address encoding won't work or has the following severe  
disadvantage (explain disadvantage)."   If you can't come up with one,  
then the conditional flag here is not only unnecessary, but harmful.

---

From: Subir Das <[email-masked]>
Date: Fri, 16 Jan 2009 18:11:31 -0500

> not changing my guidance.  I think MIPSHOP should pick one encoding
   Does this mean we can define two separate options: one for IP address 
and other one for FQDN
   without using 'enc' byte?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Jan 2009 15:25:40 -0800

>   without using 'enc' byte?

Subir, can you answer the question as to why you want both options?    
Having a second option still creates a situation where the implementor  
will probably prefer one code path over the other, and we'll wind up  
with lots of implementations that support one path well and fail when  
operator chooses the other path.

---

From: Subir Das <[email-masked]>
Date: Fri, 16 Jan 2009 18:35:54 -0500

> then the conditional flag here is not only unnecessary, but harmful.

   We have few scenarios for which we proposed both IP address and 
FQDN.  For example, when mobile node is in home network, DHCP server 
will know the IP address and sending an IP address is sufficient. In 
roaming
   case, visited network may not have the service available and 
therefore DHCP server can not be configured with  the correct MOS IP 
address. On the other hand, visited network may know the domain name 
where service is
   available. In  such cases, DHCP server can be configured with the 
domain name. If MN obtains such  domain name it can make appropriate DNS 
query for the MoS address. Now if the current 'enc' byte in the 
sub-option is
  not the correct way to go,  can we propose two separate options?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Jan 2009 15:46:14 -0800

On Jan 16, 2009, at 3:35 PM, Subir Das wrote:
> will know the IP address and sending an IP address is sufficient.

Okay.

> In roaming case, visited network may not have the service available  
> and
> where service is available. In such cases, DHCP server can be  
> configured with the
> query for the MoS address.

I do not understand the data flow here.   Can you explain which device  
does what in this situation?   If the DHCP server doesn't know the IP  
address, how does it know the FQDN?

> Now if the current 'enc' byte in the sub-option is not the correct  
> way to go,  can we propose two separate options?

That's not really the issue.   Let's resolve the technical details  
first, and then talk about how to implement it.

---

From: Subir Das <[email-masked]>
Date: Fri, 16 Jan 2009 18:59:07 -0500

Ted Lemon wrote:
>> In roaming case, visited network may not have the service available and
    DHCP Server in the visited network is configured with the FQDN of 
the provider that provides the mobility service. When MN arrives to this 
visited network, it sends the MoS option to the DHCP Server and
    receives  the FQDN of the provider. MN then sends the DNS query to 
the provider and obtains the address of the Mobility Server (MoS).  The 
FQDN of the service provider may be known
    via roaming agreement.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 16 Jan 2009 16:13:54 -0800

> FQDN of the service provider may be known

Why can't the DHCP server resolve the FQDN itself and return the IP
address(es) to the DHCP client?  It seems to me that the scenarios above may
make a case for the server being configured with both IP address and FQDN
but that's all.

> > first, and then talk about how to implement it.

What a concept! ;-)

---

From: Subir Das <[email-masked]>
Date: Sat, 17 Jan 2009 11:15:42 -0500

> have to resort to hex presentation.
  Thanks and I  understand David and Ted's concerns. Hopefully we will 
be able to resolve this
  soon.
 
> My own feeling is that the 'encoding' field is a de-facto standard, and we 
    I would wait for David or Ted to comment on this.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 17 Jan 2009 22:35:51 -0500

Just for the record, there are DHCP server implementations that do
support this encoding-byte + data (depending on encoding-byte) format.

And, the RFC 3495 (CableLabs Client Configuration Option) is used by
lots of devices.

As it is used in several places, I do think the cat is out of the bag
and I think it should be usable by new options.

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ted Lemon
Sent: Friday, January 16, 2009 1:25 PM
To: David W.Hankins
Cc: Dhcwg; Chairs; [email-masked];
[email-masked]
Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 17 Jan 2009 22:37:52 -0500

While a DHCP server could do that, it would provide the answers at
whatever time the server resolved it (sure, I suppose it could honor the
TTL on the data and only cache it for that long). But, that doesn't
solve the problem of why a FQDN was desired -- the option might not be
used for hours or days and by then the addresses could have changed.
Once the client is given the lease and options, it won't get new ones
until it renews.

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Glen Zorn
Sent: Friday, January 16, 2009 7:14 PM
To: 'Subir Das'; 'Ted Lemon'
Cc: 'Dhcwg'; 'Mipshop Chairs';
[email-masked]
Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options

and
> >> domain name. If MN obtains such  domain name it can make
appropriate
DNS

Why can't the DHCP server resolve the FQDN itself and return the IP
address(es) to the DHCP client?  It seems to me that the scenarios above
may
make a case for the server being configured with both IP address and
FQDN
but that's all.

What a concept! ;-)

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 18 Jan 2009 14:53:58 -0800

> used for hours or days and by then the addresses could have changed.

OK, so why the option for IP addresses?  I what you say is true for the
roaming case, why isn't it also true for the home network?  One way or the
other, it seems like one of these options make no sense...

...

Play assigns meaning to human activity --  work erases it.
  -- P.L. Wilson

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 18 Jan 2009 20:24:28 -0500

I wasn't answering with respect to this draft, but the general case for
why a FQDN may not always be 'best'.

The reason why address was used in other cases was because the DHCP
client might have limited capabilities at the time the option is needed
and not have a DNS 'client'. Or, there may be cases where the target
("server") does not have a FQDN.

I don't know if either of these are an issue in this particular case -
if these devices are assumed to always have a DNS resolver and the
target a FQDN, then just providing the FQDN would be the best.

- Bernie

-----Original Message-----
From: Glen Zorn [mailto:[email-masked]] 
Sent: Sunday, January 18, 2009 5:54 PM
To: Bernie Volz (volz); 'Subir Das'; 'Ted Lemon'
Cc: 'Dhcwg'; 'Mipshop Chairs';
[email-masked]
Subject: RE: [dhcwg] Status of draft-ietf-mos-dhcp-options

OK, so why the option for IP addresses?  I what you say is true for the
roaming case, why isn't it also true for the home network?  One way or
the
other, it seems like one of these options make no sense...

...

---

From: Subir Das <[email-masked]>
Date: Sun, 18 Jan 2009 23:55:47 -0500

> And, the RFC 3495 (CableLabs Client Configuration Option) is used by
   That was my understanding too. Also RFC 3361 is accepted by 3GPP IMS.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Jan 2009 01:33:53 -0700

> FQDN of the service provider may be known

Subir and I wound up talking about this a bit offline.   It appears to  
be the case that what is being proposed here is that in some cases it  
will be necessary to send the FQDN rather than the IP address because  
the DNS server would provide a different answer to a query coming from  
a mobile host than it would to the DHCP server.

So essentially the motivation for the strangeness of this DHCP option  
is to provide a platform for standardizing incorrect behavior on the  
part of DNS servers.

So what I suggested to Subir is that perhaps he should make a  
presentation explaining what he intends to the DNSOP working group and  
see what kind of reaction he gets to this proposal.   On the surface,  
it seems like this is simply the wrong solution to the problem, and  
that perhaps a deeper rethink of the whole spec is called for.

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 19 Jan 2009 12:43:27 -0800

> ("server") does not have a FQDN.

I wouldn't have thought so.  I would say addresses are the most
simple answer to the question posed by configuration, and
consequently our most frequent (Keep It Simple) candidate.

When I look at drafts such as these, I try to ask myself 'what benefit
does the protocol gain by having the client perform DNS queries to
resolve the name'?  Most frequently, I find to my own inspection that
there either is no benefit, or that the DNS is not unique in
requirements to solve it (it can usually be solved trivially with
existing tools of DHCP server configuration).  I don't trust my own
inspections, as I do not follow the work of other WG's closely.

Back to this case's FQDN usage model to illustrate...

I believe the draft currently suggests the client is expected to find
NAPTR and SRV records, to my inspection providing client-based load
balancing and port number assignments as benefits to the protocol.

DHCP server configuration provides load balancing, and the port number
assignment can be fulfilled by using a 6-octet IPv4-address-plus-port
for the option formats (18-octet for v6).

So one way to look at it is to ask what benefit is required that only
the DNS can provide, thus providing a technical answer to why the DNS
must be included as an additional moving part in this picture.

Having done so, use the FQDN format as the single format for the
options.  Having not done so, stick with binary representations.

> target a FQDN, then just providing the FQDN would be the best.

Unless of course you were concerned about resource or time costs
associated with the extra packet exchanges to finally result in a
configured client, or the extra burden placed upon a client to make
intelligent decisions (such as honoring client-based load balance
methods).

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Jan 2009 22:54:58 -0700

On Jan 19, 2009, at 6:02 PM, Vijay Devarapalli wrote:
> It is not clear to me why the DHC WG is discussing the scenarios for
> MIH server discovery.

Because we would like to understand the requirement for the complex  
option you have proposed, and specifically why the simpler version we  
have suggested is not acceptable.

> For more information on the scenarios, see
> http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mstp-solution-11.txt 
> .
> This document is also currently with the IESG.

Right, it appears that the two scenarios you are trying to address are  
the ones in sections 5.1 and 5.2.   Neither of these appears to  
require that the DHCP server send an FQDN to the client.

> For those who are not familiar with how DNS is used in cellular
> networks, the FQDN can change quite a bit based on the roaming
> scenarios.

If the FQDN is what is varying, then there is no need to send the  
FQDN, since it doesn't matter where the resolution happens.   As a  
matter of practice, DHCP servers are normally configured with FQDNs,  
and resolve them on demand, before responding to DHCP clients.   So in  
the cases you've described, the only avenue whereby the FQDN can be  
communicated to the DHCP client is through the DHCP server, and since  
the DHCP server can resolve the FQDN itself, there is no need for the  
option to support the added complexity of being able to send either an  
IP address or an FQDN - the IP address is completely sufficient.

> Please be assured that we do need the capability to convey either the
> IP address or the FQDN of the MIH server to the mobile node via DHCP.

The point of us (the DHC working group) reviewing these drafts is that  
we have a lot of knowledge about best practices for DHCP.   Based on  
the draft you've asked us to review, and the draft you suggested we  
look at just now, there appears to be no such requirement.

I'm sorry to be pushing back like this - I know you have work to do  
and would like this to proceed with as few roadblocks as possible.    
The reason I'm advising you to make the change I've suggested (sending  
only the IP address) is that I think that in the long run this will  
get you to reliable, widely deployed, interoperable running code  
sooner.   If you do have a real requirement for the ability to switch  
between FQDNs and IP addresses in the option, then you don't have a  
choice.   But as far as I can tell you do have a choice, and I'd  
really encourage you to consider taking the easier option.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 20 Jan 2009 08:18:47 +0200

I don't think we have the non-standard DNS behaviour in any of the IETF 
specifications around this functionality. Of course, I cannot guarantee 
that people are not doing it in their specific deployments, nor have I 
read the IEEE 802.21 spec in its entirety. Let me know if I have missed 
something...

In any case, my preliminary conclusion from the earlier part of this 
thread is that conditional formats in DHCP options are not necessarily a 
good idea. That still leaves it possible for us to do both an address 
based option and a FQDN based option, if we really need them. But I 
agree with Ted that this is a good time to re-evaluate whether both are 
actually needed.

If you read mipshop-mos-dns-discovery and mipshop-mstp-solution, you'll 
see that there's quite a bit of SRV, NAPTR etc machinery* around this as 
well. I don't think we have all the mechanisms in the DHCP option to 
replace these (e.g., choice between TCP and UDP, port numbers).

But I have not seen a convincing argument why an FQDN-only DHCP option 
would be problematic. Even in situations where you will be delivering 
the address of a local server, presumably that local server is also in 
the DNS, so passing a FQDN would also be fine.

Jari

*) Not all of it is yet in shape to move forward. Ignore those details 
for the purposes of this discussion.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Jan 2009 02:05:40 -0700

> the DNS, so passing a FQDN would also be fine.

The only reasons to avoid FQDN-only are that it takes more space in  
the packet (possibly not an issue here, but I don't have a clear  
picture) and that it requires the client to do name resolution  
(obviously not a problem here).   I tend to recommend the IP-address  
mechanism because of packet space and ease of implementation on the  
client, but you're right that there's no strong reason to choose one  
over the other.

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 19 Jan 2009 17:02:54 -0800

It is not clear to me why the DHC WG is discussing the scenarios for
MIH server discovery. For more information on the scenarios, see
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mstp-solution-11.txt.
This document is also currently with the IESG.

For those who are not familiar with how DNS is used in cellular
networks, the FQDN can change quite a bit based on the roaming
scenarios. Sometimes the operator code and the country code are
embedded in the DNS string. Sometimes the type of mobility anchor,
GTP-based or Mobile IP-based is also encoded in the FQDN. In the MIH
scenarios, the type of MoS server is encoded in the FQDN. The DHCP
server would be dumb. Some network element would tell the DHCP server
what to convey to the mobile node.

draft-ietf-mipshop-mos-dhcp-options only provides a part of the
solution, i.e, define the DHCP options for carrying the MIH server
information.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Jan 2009 12:18:38 +0200

Lets try to conclude this thread. I was under the impression that 
avoiding the "enc" field was acceptable to everyone, if we can still do 
what we need to do with other option(s).

What I have not heard enough about yet is whether the two options are 
actually needed. Subir, I proposed simply transporting the FQDNs, and I 
though that would actually avoid all the issues raised so far. Can you 
see any problems with that?

Jari