> 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.)
> 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.
Erik
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
