Erik, Erik Nordmark wrote: > > > If the app says [6 months, 6 months] then personally I would expect the > > host to fail the request if it only has a unicast prefix lifetime of 1 > > week. > > I think your question is really: should we allow such a host to grant > > a request for 6 months if it only has a unicast prefix lifetime of 1 > > week? > > Bingo! > > The related question is: are there applications which would fail to function > today if you applied the constraints imposed by this today i.e. the > fact that no multicast addresses could be allocated by the API > with an end time more than a week into the future? > (For this excercise it would make sense to consider the IPv4 multicast > applications as well as the IPv6 multicast applications that exist just > to try to understand the scope of the applications dependency on multicast > address lifetimes.)
As I said in an earlier response, this is not a v6 specific issue. Applications/stacks/nodes/etc. using MAPCAP in v4 will have to deal with the aspect of mcast address leases not filling their initial lifetime requests. Maybe someone with more operational experience than me with MAPCAP allocated addresses will describe how they deal with lease renewal and advertisement issues. I don't see usage of dynamically allocated addresses being requested weeks in advance for one day use. I could be wrong, but I haven't seen any behave in that manner. > > > In my previous email, if there is a need to allow this (and I'm not > > saying > > there is), then we'd have to just say it SHOULD NOT, and say that after > > the unicast lifetime, the multicast packets are not guaranteed to be > > routed. > > I fail to understand why routing might fail. Could you explain? > I do understand that there is a different probability of allocating duplicate > uni-based mcast addresses should the unicast prefix be assigned to another > entity, but this doesn't lead to routing failing unless you are assuming > that routing will do something it doesn't currently do. I think one possible example is with SSM. The first hop router may receive an IGMPv3 join with an old prefix that has been renumbered. It then tries to send the SPT Join to the wrong network. That network doesn't exist and so the Join fails and the multicast traffic never flows. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
