Subject: [dhcwg] review request for draft-das-mipshop-andsf-dhcp-options

From: Jari Arkko <[email-masked]>
Date: Tue, 22 Jun 2010 12:57:24 +0300

DHC WG,

This is a draft that has been submitted to me for publication as a
Proposed Standard. It is an individual submission, driven mainly by
some 3GPP interests, but it has also been reviewed in the MIPSHOP WG. I
have made my AD review on it (see below), but my records do not show
that it would have been reviewed in the DHC working group. Please take
a look at this draft:

http://tools.ietf.org/html/draft-das-mipshop-andsf-dhcp-options

Jari

I have reviewed this draft.

It is basically in good shape and can move forward. I had one major
technical question which we can hopefully resolve easily with the help
of DHCP experts, and two relatively minor updates to the security
considerations text.

I will ask the DHC WG to review this draft as well, and would also like
to ask the authors to revise the draft according to the comments as
soon as possible.

Technical:

I am not particularly fond of the practice to define both address and
DNS versions of the same option, but I can live with that.

In case that the server cannot find any ANDSF Server satisfying
the requested Option Code, the server MUST return the ANDSF Option
by setting the Option Code to the requested Option Code and the
length of the Option to 0.

This seems to be in conflict with advice from RFC 3315:

If the client has included
an Option Request option in the Solicit message, the server includes
options in the Advertise message containing configuration parameters
for all of the options identified in the Option Request option that
the server has been configured to return to the client.

In other words, do we return empty options, or no options, for the
stuff that the server does not recognize or does not have configuration
information for?

This issue may exist on the DHCPv4 side as well.

I would like to ask the DHCP experts to explain what the recommended
approach is here. (The draft will need to be reviewed by the DHC
working group anyway.)

7. Security Considerations

The security considerations text should probably highlight the
importance of securing the actual ANDSF as opposed to securing merely
the discovery phase. This way you can also avoid reliance on
recommending something that is not in practice going to happen (DHCP
authentication).

In deployments where DHCP authentication is not available, 3GPP
specific lower layer security services may be sufficient to protect
DHCP messages.

... except in non-3GPP network access scenarios :-) I would suggest
simply saying "... specific link layer security services may be
sufficient ..."

Editorial:

ANDSF is specified in [3GPPTS23.402].

I'd prefer to not have references in the abstract so that it can stand
on its own. Perhaps this sentence can be removed and only retained in
the introduction?

and selection assistance data to the mobile nodes for multi-access

network scenarios where 3GPP access-network level solutions are not

Extra empty line.

selection of non-3GPP networks[3GPPTS23.402].

missing space between the last word and the "[" character.

When the DHCP server receives either an ANDSF IPv4 Address Option or
ANDSF Domain Name List Option in the PRL, the DHCP server MUST
Include the option in its response messages (as defined in [RFC2131])
that may contain a list of one or more IP addresses or a list of one
or more FQDNs of the ANDSF server hosting the service.

I thought that the server's PRL behaviour was actually defined in
RFC2132. But I could be mistaken.

6.2.1 Mobile node behavior

Different indentation (spaces before the section number) confuses the
IETF tools document htmlization.

This document also defines two DHCPv6 options as described in
Sections
4 and 5.

Indentation problems.

[3GPP TS23.402] www.3gpp.org/ftp/Specs/html-info/23402.htm
3GPP TS 23.402 V8.8.0 (2009-12): Architecture
enhancements for non-3GPP accesses (Release 8)

[3GPP Ts 24.302] www.3gpp.org/ftp/Specs/html-info/24302.htm
3GPP TS 24.302 V8.4.1 (2009-12): Access to the 3GPP
Evolved Packet Core (EPC) via non-3GPP access
networks; Stage 3;(Release 8)

Inconsistent capitalization and spacing.

Jari

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Jun 2010 11:14:12 -0700

On Jun 22, 2010, at 2:57 AM, Jari Arkko wrote:
> DHC WG,
> 
> This is a draft that has been submitted to me for publication as a Proposed Standard. It is an individual submission, driven mainly by some 3GPP interests, but it has also been reviewed in the MIPSHOP WG. I have made my AD review on it (see below), but my records do not show that it would have been reviewed in the DHC working group.

This document seems to specify two sets of two options, one set for DHCPv4 and DHCPv6.   So these comments apply to each set of two options:

First, it appears that this draft provides two different ways whereby the DHCP client can be configured with the IP address of the ANDSF server:

	- it can receive an FQDN from the DHCP server, and then use DNS to translate that into an IP address
	- the DHCP server can be configured with an FQDN, which it translates into an IP address

There is no reason to provide both options.   The way most services do this is to configure the DHCP server with either FQDNs or IP addresses, and, in the case of FQDNS, have into IP addresses.   When you specify two mechanisms for accomplishing the same purpose, you create the possibility of an interoperability problem.   What if the client asks for IP addresses, but the server is only configured to send FQDNs?   Do you want special case code in the server that notices that it has FQDNs, and sends those when FQDNs are requested, but sends IP addresses when IP addresses are requested?   We strongly discourage any such requirement.

So if I've correctly understood how you are using FQDNs here, I strongly recommend that you eliminate the FQDN options entirely, since they are unnecessary.   If you feel that it is crucially important to preserve DNS semantics--if you think the MN is going to pay attention to the TTL and re-look up the IP address when it expires--then eliminate the IP-address-only option.   But unless you are considering that to be part of the MN's operational requirements, just use IP addresses, because they consume less space in the DHCP packet, and space is tight.

>    length of the Option to 0.

This implies that the DHCP server is using some sort of service discovery process to locate ANDSF servers.   DHCP servers cannot be required to do this.   It further implies that when the server has not been configured with an option, it should send a zero-length option.   This requires special-case code in the server, and is not appropriate.

Since by default DHCP does not send options when no values have been configured, the correct way to address this is to delete the text I've quoted entirely, and add text on the client side saying what to do if no ANDSF options are received.

Other than that it looks fine... :'}

---

From: Jari Arkko <[email-masked]>
Date: Tue, 22 Jun 2010 21:30:35 +0300

Agree on the part about returned zero length options.

On the FQDN & IP issue: as I stated, I'm not too happy with this either, 
but I understood that the 3GPP had requirements to support both cases. I 
can sort of understand the desire to use FQDNs, because, for instance, 
that enables you to configure the name of a server in a home network, 
and then the access network operator does not have to worry about what 
the IP address for that server is today. Using an FQDN also gives you 
the ability to specify several alternate servers, without having to list 
them all in the DHCP message.

Its less clear to me what the need for the IP address-based option is. 
Is it merely space & elimination of an additional DNS exchange? I'm not 
very convinced about that. Say, if you have to deliver two addresses to 
provide an alternate. And if these addresses are IPv6 addresses, that's 
already 32 bytes. I suspect there might be cases where the FQDN approach 
would actually lead to shorter DHCP messages.

So my question is: what, if anything, we lose by just specifying the 
FQDN version of the option?

(On positive news, this draft is loosely modeled after RFC 5678. Luckily 
this draft is considerably simpler, because in RFC 5678 we had the added 
complexity of sub-options and server types.)

Jari

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Jun 2010 15:08:19 -0700

On Jun 22, 2010, at 11:30 AM, Jari Arkko wrote:
> I can sort of understand the desire to use FQDNs, because, for instance, 
> the IP address for that server is today.

That's also true for IP address options: the DHCP server looks the FQDN up in the DNS when the request comes in, and sends the response to the client as an IP address.   The result when the DHCP transaction happens is exactly the same whether the client or the server does the lookup.

What differs is that if the client caches the name and uses the TTL on the RR, and if the TTL is shorter than the DHCP lease time, then the client would notice a change in server IP address sooner if it did the lookup than if the DHCP server did the lookup.

I would be not merely surprised, but *astonished*, if any client implementation actually does that.   However, a case can certainly be made for allowing for clients that do that.

> Using an FQDN also gives you 

If the FQDN returns multiple IP addresses, the DHCP server will return multiple IP addresses to the client.   So again this has the same effect whether the server or client does the lookup, except for the caveat I mentioned above.

> would actually lead to shorter DHCP messages.

Historically there have been two reasons stated for using FQDNs: the response is shorter, and the client is simpler.   You are correct that if the FQDN returns multiple IP addresses, there's every likelihood that in the IPv6 case, the FQDN will be shorter than the two IP addresses.   So the argument for saving space in the packet is fairly weak in the case of DHCPv6.

> FQDN version of the option?

In practice I don't think you lose anything you really care about.   I'm guessing that andsf clients are not things that live in space-constrained boot PROMs, so the usual argument of making the client simpler doesn't apply, and as you've said, the space savings are a wash for IPv6.   I certainly wouldn't object to this change.