On Mon, Feb 08, 2010 at 10:44:08PM +0000, Paul Selkirk wrote: > The biggest thing is that the Address option is a MUST, and the Name > option is a MAY ALSO: > A client that supports B4 functionality of the DS-Lite (defined in > [draft-ietf-softwire-dual-stack-lite-02]) MUST include > OPTION_DS_LITE_ADDR on its OPTION_ORO, and MAY include > OPTION_DS_LITE_NAME at its option and ability. > > I'd have expected to see the two options on an equal footing, where > clients could request one or the other without prejudice, but probably > wouldn't request both.
The problem with placing the options on equal footing is that the NAME option clearly requires a great deal more software, in addition to extra packet transmits (and RTT's) to perform DNS resolution. So for the benefit of devices where both of those are an issue, the idea is to require all clients and servers to implement the ADDR option, the smallest common denominator. Whether or not servers are configured with ADDR options when their operators have NAME options configured is an unfortunate minor side issue. But it is generally easier for an operator to configure an extra value when encountering such a client than it is to put extra software or more batteries in a client that can't implement the NAME option. > Further: > If the client requests and receives both the OPTION_DS_LITE_ADDR and > the OPTION_DS_LITE_NAME, it MUST proceed with resolving the > OPTION_DS_LITE_NAME. > > This says that the Address option is a throw-away in this context. > i.e. There's no reason to request the Address option in this context, > except that this draft mandates it. That is correct; but it's a conclusion of the above discussion, so we need to get closure there first. Because the client will request either the ADDR option or both options, it must select one above the other. In my opinion, because the resolution by DNS after DHCPv4 completes takes extra RTT and relies on client implementation, an operator wouldn't configure the NAME option unless the resolution by DNS on the client end conferred some benefit (without speculating on those benefits). Noting that the ADDR option may be configured as a DNS name in the server's configuration (resolved via DNS to be provided in the DHCPv4 response), there really has to be some benefit to the operator for the clients to be performing DNS to resolve this value (the place resolution is performed is more important than the data since otherwise it would be the same data). So if a NAME option is provided, it is considered the operator's intent for it to be evaluated. Because all clients implement (and request) the ADDR option, operators that do not see a benefit in client-side DNS resolution can simply omit the NAME option from configuration, and those clients will receive the configured ADDR option they are required to supply. It's a minor problem that they really must include an address option in configuration but may not know this. > I'd suggest something like: > A client that supports B4 functionality of DS-Lite MUST include > either OPTION_DS_LITE_ADDR or OPTION_DS_LITE_NAME on its > OPTION_ORO. If the client requests and receives both > OPTION_DS_LITE_ADDR and the OPTION_DS_LITE_NAME, it MUST proceed > with resolving OPTION_DS_LITE_NAME. You have incorrectly placed the locus of the determination of "which option should the client use?" It does not rest with the client in my opinion (above), it rests with the server operator. The only way to give the server operator that power is for the clients to request all the options they support, in the order they think they should be prioritized in the packet, and let the server determine which ones to provide or withhold. So we're requiring the ADDR option be implemented for reasons above. That limits the client's options to supplying only the ADDR option or both the ADDR and NAME option. There is a side-issue that was brought up earlier that I want to give a more detailed answer to; the problem that providing both data values in response is not optimal (wastes space). One suggestion was to update Server behaviour so that the Server sends only one of the two options at its preference if both were requested. The problem with this is that it is specific to these particular two options. The problem of option aliasing is not a new one to DHCP, we have many other option codes that alias information provided by each other. A generic solution, extending the DHCP protocol rather than encoding prioritization in the servers is desired. One approach suggested to DHC WG some time ago by Ted Lemon is to "markup" the PRL with two otherwise unused option codes that bracket options of which the client only wants one. This optimizes the data sent to the client, but makes client prioritization slightly more cumbersome to instrument (e.g., a client may want OPTION_DS_LITE_ADDR before OPTION_NAME_SERVERS, but OPTION_DS_LITE_NAME after as it's useless without it; this may be a contrived example that is not a general problem). But I digress. The point is although that particular way may not be the way the problem is finally approached, it illustrates that this is considerably a "protocol" problem and not a "data" problem, and that we have at least one "protocol" solution if or when the issue of redundant data in the DHCPv4 packet options space becomes an issue. > On to the language nits... I will have a look at these separately, I don't see anything offhand that is an issue correcting. -- 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
pgpV97qoUURJa.pgp
Description: PGP signature
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
