Minutes reported by B. Quinn and S. Hanna.
Agenda:
Agenda Bashing [Hanna]
Architecture [Hanna]
MASC Deployment [Govindan]
Language Tags [Hanna]
MDHCP Changes [Shah]
MDHCP Issues [Thaler]
Steve Hanna described the malloc architecture, explaining why dynamic allocation of IP Multicast addresses is important, what the requirements are, and how those requirements are supported by the different parts of the malloc architecture.
Steve also gave a document status update. MDHCP is expected to go to last call in January 1999. MASC, AAP, the malloc architecture, and the Abstract API should all go to last call in the spring.
Ramesh Govindan of USC/ISI gave a presentation on possible MASC deployment techniques.
In the long run, each AS will probably be its own MASC domain, with a limited number of top-level domains functioning as peers (with children of those TLDs, etc.). However, we can start out with a single root domain that injects the address sets and a small number of well-known TLDs that are children of that root. This will be simple and good for debugging.
Over time, we can move to a more decentralized model with children of the TLDs, shortcuts between the TLDs, and the eventual elimination of the root TLD.
Ramesh briefly outlined the latest changes to the MASC protocol: refining processing of UPDATE messages and adding type-based ordering of exchanged messages after reestablishment of peering.
Finally, Ramesh explained that a standalone implementation of MASC is being developed at USC/ISI. Alpha code should be ready by next IETF. Mark Handley announced that we have asked the IANA to allocate a range of multicast addresses for dynamic allocation with malloc.
Steve Hanna explained why language tags have been added to zone names and how they work. The problem is that zone names are user visible strings and different users speak different languages. For instance, a zone named "IBM Switzerland" would not be appropriate for someone who doesn't speak English.
The solution we have adopted is to apply RFC 1766 language tags to zone names and allow more than one name per zone. This meets requirements of RFC 2277, which says (roughly) if you have user visible strings you need to have a way to indicate which language they are in and, when appropriate, support multiple languages.
For MZAP, we have added a language tag for each zone name and added support for having more than one name per zone. We have also added a default flag, which indicates which name should be used if no language tag matches the user's preferences. A conflict in names (two routers configured with different names or language tags) indicates a configuration error.
MASC and AAP are not affected by language tags on zone names since they do not deal with zone names.
MDHCP has been modified to allow a host to specify a preferred language in the MDHCPINFORM message. The MDHCP server will return the best match for each zone. For multilingual hosts, the host should not specify a preferred language. In this case, the MDHCP server will return all names for each zone.
The Abstract API has been changed to include all zone names in the Scope data type. The get_zone_name function fetches the zone name that best matches a given language tag from a given Scope.
Munil Shah described the changes to the MDHCP specification since the last IETF. A new port number has been assigned by the IANA: 2535. The unused chaddr, sname and file fields have been removed. The MDHCP option space has been split off from the DHCP option space. And support for language tags has been added (as described above).
Dave Thaler led a discussion of unresolved issues with MDHCP. The goal was to discuss these issues and achieve consensus, then confirm this consensus on the mailing list to allow us to take the spec to last call in January, as listed in our working group charter.
Dave listed the issues scheduled for discussion and asked for any others. Two more were raised and added to the list (issues 6 and 7 below).
Before beginning the issues discussion, Dave presented a summary of the answers to a questionnaire that Steve Hanna sent to the dhcp-v4 and dhcp-impl mailing lists. 5 DHCP implementors responded.
3 Yes, 1 will accept mods, 1 if there's demand
3 Yes, 1 Maybe, 1 Little
3 Yes, 1 No Opinion, 1 Do The Right Thing
The first issue was whether the remaining reserved fields (op, htype, hlen, hops, secs, flags, ciaddr, yiaddr, siaddr, and giaddr) should be removed. The argument in favor of retaining them was to make it easier to reuse existing DHCP code. The argument in favor of removing them was that they are unnecessary and the savings due to reuse here is minimal. After much discussion, it was agreed to drop these unused fields. It was also agreed (at the suggestion of DHCP implementers) that we add a version number to the header.
The second issue was security. Dave Thaler summarized the problem by saying that our primary goal is to authenticate messages so we can check authorization. DHCP has a harder problem, since a DHCP client may not have a unicast address. The authors' proposal was to secure unicast messages with an existing security protocol (undecided which one), not secure the multicast INFORM message (used to request scope list), and require secure servers to ignore multicast DISCOVER and REQUEST messages (which would not be secured).
Ted Tso and Bob Moskowitz (cochairs of the IPsec working group) summarized the advantages and disadvantages of several existing security protocols for this purpose. First, they confirmed their understanding that we want user-based security for UDP packets. The answer was yes, since we want to be able to base authorization on user identity.
They explained that current implementations of IPsec provide host-based security. More work needs to be done on APIs and implementation before user-based IPsec will be ready. Also, installing IPsec requires OS-level modifications and IPsec is not yet widely available.
Then they discussed other possible solutions. Of these, the most promising seemed to be TLS/SSL. TLS is user-based, but it is also TCP-based. Using TLS with MDHCP would require sending the payload that would normally be carried over UDP over an authenticated TCP connection. Another advantage of TLS over IPsec is wide availability and no OS-level modifications required.
It was generally agreed that IPsec was probably the right decision long-term, but it would be difficult in the next few years to require all MDHCP clients to support IPsec. Support for user-level security in IPsec will also take a while to become available.
It was agreed that we will go with IPsec for MDHCP security, but ask the IESG to not require security in all MDHCP implementations for the time being, since IPsec deployment is just beginning. Also, even perfect security in our multicast address allocation protocols can't keep somebody from just choosing an address and starting to use it. At least, not with current implementations of IP Multicast.
Currently, each MDHCP option includes a one byte length field. We expect to exceed this length with long scope lists or address block lists. DHCP will probably move to a two byte option length field in the future. Shall we move to it now?
After some discussion, the general consensus was that we should.
The current MDHCP draft says that clients looking for a server should first look in the local scope, then the scope from which they're trying to allocate, then the Allocation Scope. Unfortunately, there is no document defining Allocation Scope yet. The authors recommend removing all mention of Allocation Scope from the document.
It was pointed out that this would require you to have an MDHCP server in each scope from which you want to allocate. Also, unless you use DHCP (or some other mechanism) to provide an MDHCP Server Multicast Address, you would need to have an MDHCP server in each local scope where you have MDHCP clients.
It was also pointed out that providing MDHCP services for a scope when the server is not in that scope is very difficult. The server must know exactly which scopes the client is in and which addresses are available in those scopes. This is not easy and not recommended at this point.
It was agreed to remove all mention of Allocation Scope from the document. Use of MDHCP with the Allocation Scope may be defined by a future RFC, once the Allocation Scope has been defined.
Currently, MDHCP only supports IPv4. The authors recommend adding address type fields to allow MDHCP to support IPv6. We quickly agreed to this recommendation.
Currently, each MDHCP option includes a one byte option code. Based on DHCP's experience of running low on option codes and their decision to move to a two byte option code in the future, we quickly agreed to move to a two byte option code for MDHCP.
It was also suggested and agreed to number our options from 1 instead of attempting to match them to DHCP option numbers.
Steve Deering suggested that since MDHCP has diverged from DHCP, it might make sense to change its name. After some discussion, this was agreed. Discussion of what the new name should be was moved to the list.