NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98
Chair(s):
Steve Hanna <steve.hanna@sun.com>
David Thaler <dthaler@microsoft.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@ee.lbl.gov>
Transport Area Advisor:
Vern Paxson <vern@ee.lbl.gov>
Technical Advisor(s):
Thomas Narten <narten@raleigh.ibm.com>
Mailing Lists:
General Discussion:malloc@catarina.usc.edu
To Subscribe: malloc-request@catarina.usc.edu
Archive: catarina.usc.edu/pub/multicast/malloc/
Description of Working Group:
Note: This Working Group is co-chartered in the Internet Area.
Multicast address allocation is an essential part of using IP multicast. Multicast addresses are an even more limited resource than unicast addresses, and must be allocated dynamically if they are to satisfy expected demand. To this end, the MALLOC WG will define three protocols which work together to form a global dynamic multicast address allocation mechanism. These protocols will be:
- a "host to Address Allocation Server" protocol used by a host to obtain one or more multicast addresses from an address allocation server within its domain.
- an intra-domain server to server protocol that address allocation servers within the same domain can use to ensure that they do not give out conflicting addresses.
- an inter-domain protocol to provide aggregatable multicast address ranges to domains, which the servers in that domain can then allocate individual multicast addresses out of. This protocol will work in conjunction with the IDMR WG's Border Gateway Multicast Protocol to provide a scalable inter-domain multicast routing solution.
Although mechanisms for enforcing policies for multicast address allocation may be considered, setting any such policies is not within the scope of this WG. Alternative multicast models are also out of scope.
Goals and Milestones:
May 98 |
|
Repost the architectural framework, including the abstract API model for allocating addresses, as WG Internet-Draft(s). |
Aug 98 |
|
Report on simulation and implementation efforts with existing protocol proposals. Address any problems in the specifications that were found. |
Oct 98 |
|
Post MIBs for the three levels as Internet-Drafts. |
Dec 98 |
|
Meet at Orlando IETF. Review and finalize the host-server protocol. |
Jan 99 |
|
Submit the host-server protocol to the IESG for consideration as a Proposed Standard. |
Jan 99 |
|
Submit the MIB for the host-server protocol to the IESG for consideration as a Proposed Standard. |
Jan 99 |
|
Submit the architecture and abstract API document(s) to the IESG for consideration as Informational. |
Apr 99 |
|
Submit the inter-domain protocol to the IESG for consideration as a Proposed Standard. |
Apr 99 |
|
Submit the MIB for the intra-domain protocol to the IESG for consideration as a Proposed Standard. |
Apr 99 |
|
Submit the intra-domain protocol to the IESG for consideration as a Proposed Standard. |
Apr 99 |
|
Submit the MIB for the inter-domain protocol to the IESG for consideration as a Proposed Standard. |
Internet-Drafts:
· The Multicast Address Set Claim (MASC) Protocol
· Multicast address allocation based on the Dynamic Host Configuration Protocol
No Request For Comments
Minutes of MALLOC Working Group
IETF 43 (Orlando, FL)
Thursday, December 10, 1998
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
I. MALLOC Architecture
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.
II. MASC Deployment
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.
III. Language Tags
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.
IV. MDHCP
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).
V. MDHCP Issues
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.
Do you think that you might implement an MDHCP client or server?
3 Yes, 1 will accept mods, 1 if there's demand
If you were to do so, would you attempt to share code with your DHCP client or server?
3 Yes, 1 Maybe, 1 Little
Do you think that we should continue to maintain a similarity between MDHCP and DHCP?
3 Yes, 1 No Opinion, 1 Do The Right Thing
*Issue 1* Unused Fields
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.
*Issue 2* Security
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.
*Issue 3* One-byte option length
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.
*Issue 4* Allocation scope referenced but not defined
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.
*Issue 5* IPv6 support
Currently, MDHCP only supports IPv4. The authors recommend adding address type fields to allow MDHCP to support IPv6. We quickly agreed to this recommendation.
*Issue 6* One-byte option code
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.
*Issue 7* MDHCP Name Change
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.
Malloc Architecture
Language Tags in Malloc
Multicast Address-Set Claim (MASC) Deployment
MDHCP Open Issues Discussion