Multicast Address Allocation WG (malloc) Thursday, March 30 at 0900-1130 =============================== CHAIRS: Dave Thaler Steve Hanna AGENDA: Agenda Bashing Introduction and Document Status Dave Thaler (5 minutes) AAP Updates: Mark Handley (30 minutes) draft-ietf-malloc-aap-03.txt MALLOC MIB Update: Dave Thaler (10 minutes) draft-ietf-malloc-mib IPv6 Multicast Address Allocation: Brian Haberman (5 minutes) draft-haberman-malloc-ipv6-prefix-00.txt draft-haberman-ipngwg-mcast-arch-00.txt ---------------------------------------------------------------------- Document Status ---------------- Two RFCs were published since the last meeting: MADCAP is now RFC 2730 (Proposed Standard) Abstract API is now RFC 2771 (Informational) Three documents were sent to IESG since last meeting: Architecure Document (submitted for Informational) MADCAP Scope Nesting Option (submitted for Proposed Standard) MASC (submitted for Experimental) Other WG Documents remaining: AAP MIB (blocked on AAP) AAP Updates: Mark Handley draft-ietf-malloc-aap-03.txt ---------------------------- lots of changes in 02 only explanation changes in 03 changes from 02 - 03 - Scaling Analysis (section 6) added: some errors, needs to be revised again - Reccomendation that hosts use MADCAP instead of AAP if a MADCAP server is available - Added discussion of allocation conflicts Beau Williamson asked: include text on how apps should deal with shifting addresses within a session? E.g. when we have an allocation conflict Dave Thaler responded: Not in AAP, this is part of session advertisements, this is something that is explained in the architecture document. - Added examples (Appendix A) - Noted reserved port number: 2878 - Removed Appendix D (Unresolved Issues) recap from 01 - 02 1) - Originally AAP assumed that could be large numbers of AAP speakers in a domain. e.g. sdr might speak AAP - this no longer the intent - can now use simpler algorithm for defending addresses * use unform random backoff, not exponential random backoff - aim is for approx 2-10 AAP speakers in a domain, with 1000 being the upper bound 2) Security mechanim - Use IPSec AH instead of custom authentication - Currently only use manual keying with a group-shared key - SMuG is working on group-keying mechanisms for later on What's next 3/00 Currently in WG last Call 4/00 Send to IESG, IETF Last Call 5/000? IESG approves as Proposed Standard other docs will be discussed in zeroconf or mboned as approriate MALLOC MIB Update: Dave Thaler draft-ietf-malloc-mib-02.txt ---------------------------- RFC2465 - defines IPv6Address type - IPv6-specific MIBs can use this draft-ops-endpoint-mib-07.txt - defines protocol-independent InetAddress type - should be RFC soon - protocol-independent MIBs should use this Changes to the MALLOC MIB - IPv6 support now uses standard InetAddress types - Updated MIB Boilerplate text - Language names now use Language Tag type defined in Multicast MIB - Added Guid type to identify leases - Reading key now MUST return empty string (was MAY) (Thanks to Lars Viklund for reviewing this MIB) ToDo - Prefix coordinator config * Has interval but not ranges to advertise - Security * currently has old "public key" objects IPv6 Multicast Address Allocation: Brian Haberman draft-haberman-ipngwg-mcast-arch-00.txt --------------------------------------- presented in IPNG WG Objectives - - Simplify IPv6 multicast address allocation - - Aid in debugging IPv6 multicast networks - - Single-source IPv6 multicast Architecture change proposal - - borrow the idea from GLOP, but include the network prefix of the allocation domain in the mcast address - - can do this as only the bottom 32 bits actually get used +---------+-----+----------------+----------+ | prefix | len | unicast prefix | group id | +---------+-----+----------------+----------+ prefix is the multicast prefix to be reserved for this purpose len is length of unicast prefix Multicast Debugging - - Who owns the multicast address - - Who allocated the multicast address Single-Source Multicast - - set "unicast prefix" to 0/0 This doc will been adopted as a WG document by the IPNG WG IPv6 Multicast Allocation Guidelines: Brian Haberman draft-haberman-malloc-ipv6-prefix-00.txt ---------------------------------------- - - short document that describes guidelines for MAAS's for generating the low 32-bits of multicast addresses so as to avoid layer-2 clashes. - - use pseudo-random address, avoiding group IDs reserved by IANA for the All-hosts, All-routers, etc groups. - - should this be a malloc WG doc? Thaler: must make explicit assumption that allocation of unicast implies allocation of multicast prefix as well. There are content provides who would like to use scope to construct borders around countries etc. Is there enough richness there to allow these things? Thaler: out of scope this WG is about allocation Haberman: new IAB doc on scoped address architecture Thaler: current IPv6 draft says that scopes must nest, can't define "arbitrary" ones unless they nest. Handley: arbitrary scopes are hard to do beacuse they must be convex...you will create black holes Handley: yes, this should be a malloc WG doc, it should probably be "proposed" 239 vs 232 Discussion ---------------------- Q: What addresses should be used for IPv4 source-specific, scoped groups? A 1) is to take one piece of the 232 range and divide it up for scoping things. Arg is don't do this as it makes advertising and filtering more difficult. 2) is to take a piece of each 239 subrange and make it source-specific. Arg is 239 is set aside as being scopable but not as source-specific. This can expand downwards into 238, though. 3) take 238 and carve it up just like 239, and distribution is the same. So MZAP announcement for (say) 239.192/16 implies that 238.192/16 is a source-specific range with the same distribution scope. This is much closer to the IPv6 proposal discussed earlier, where a single bit in the address can identify (independent of scope) whether the address is source-specific or not. Casner: just let certain scopes in 239 be used as SSM Holbrook: if we make the 232 range dynamic, then routers do become the MZAP servers? Handley/Casner: we need to keep 232 clean. If we put structure in then we will run into allocaiton conflicts at scope boundaries. Handley: we could use MZAP to indicate SS range within 239, this would require that ALL routers that could have local hosts listen to MZAP in this range. Thaler: If you're running IGMP then you could have local hosts. The argument for 238 is that routers can filter on all of 238. Casner: my main concern with 238 is fragmentation email list: ssm@external.cisco.com Actions: 1) Roger Kermode to resubmit MADCAP Nesting State Option Draft to IESG after incorporating comments from ADs 2) Mark Handley to fix scaling analysis in AAP draft and resubmit for WG last call 3) Brian Haberman to generate new document for immediate WG last call 4) Dave Thaler to generate new MIB and resubmit for WG last call Thanks to Roger Kermode for taking minutes.