From multimob-bounces@ietf.org Fri Jun 01 04:46:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu2lI-0004U5-DX; Fri, 01 Jun 2007 04:45:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu2lH-0004Tt-Pn for multimob@ietf.org; Fri, 01 Jun 2007 04:45:31 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu2lD-0001Jq-Qr for multimob@ietf.org; Fri, 01 Jun 2007 04:45:31 -0400 Received: by py-out-1112.google.com with SMTP id a25so1228546pyi for ; Fri, 01 Jun 2007 01:45:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=X9aQzgN7TYwrwB+ktanTbafFkjnJF67PUfi1bPcs6Z/V+6cNyThUNE/GbAQadJRBrlwbMmqMpIJDelMw7bagCzpr2PCZcqTlhTNvybEPqGdV+xmheDsp+siBZvk4LCiuUB6+vS8gyisBLIMg5hqd7LDKAC0Bd3qPpId2F5Nnf9Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=pYuj69zE1KtAZLwJk0vprdzk8mS3akgE5vu9AE2JTh4FnJ5XKov/B99yokvjXMFSCDqqNDWqGZ1KeAzyC09Q6OP/Znk4o5QS5c1s6xMqzG99US/TWEMZh69SXkWhXYBDoNlGaF0qtesclEK3N2fkhbyusz6thC8P994+zIUs4z4= Received: by 10.64.199.8 with SMTP id w8mr2668016qbf.1180687526660; Fri, 01 Jun 2007 01:45:26 -0700 (PDT) Received: by 10.65.176.18 with HTTP; Fri, 1 Jun 2007 01:45:26 -0700 (PDT) Message-ID: Date: Fri, 1 Jun 2007 10:45:26 +0200 From: "Jong-Hyouk Lee" To: "Shariq Haseeb" Subject: Re: [multimob] MIPL Based Multicast In-Reply-To: <19D0161D-4FA6-44B6-AD2C-CB3C3F5169EA@mimectl> MIME-Version: 1.0 References: <19D0161D-4FA6-44B6-AD2C-CB3C3F5169EA@mimectl> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9aa22b77adc37e7d33e29644e4dc0b33 Cc: multimob@ietf.org X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1588649248==" Errors-To: multimob-bounces@ietf.org --===============1588649248== Content-Type: multipart/alternative; boundary="----=_Part_3722_21232594.1180687526599" ------=_Part_3722_21232594.1180687526599 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear colleague. I agree with you. MIPL is a nice implementation for MIPv6. Absolutely, right. But, I just want to ask to Tony, what's the plan to implement for mobile multicast? I'm also interested in the implementation for mobile multicast. Cheers. On 5/29/07, Shariq Haseeb wrote: > > Hi Jong-Hyouk, > > I would just like to give my comments on Multicast and MIPL. I have done > some work on mobile multicast with MIPL. What specific areas or applications > of multicast are you interested in? > > MIPL is a good implementation. I feel it is a very stable MIPv6 > implementation. > > Rgds, > Shariq > > ------------------------------ > *From:* multimob-request@ietf.org > *Sent:* Tue 5/29/2007 3:11 PM > *To:* multimob@ietf.org > *Subject:* multimob Digest, Vol 2, Issue 7 > > > > Send multimob mailing list submissions to > multimob@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/multimob > or, via email, send a message with subject or body 'help' to > multimob-request@ietf.org > > You can reach the person managing the list at > multimob-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of multimob digest..." > > > Today's Topics: > > 1. Re: Re: multimob Digest, Vol 2, Issue 4 (Jong-Hyouk Lee) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 29 May 2007 16:11:35 +0900 > From: "Jong-Hyouk Lee" > Subject: Re: [multimob] Re: multimob Digest, Vol 2, Issue 4 > To: guanjian8632@163.com > Cc: multimob@ietf.org > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Dear Tony. > > I'd like to ask you. In the previous e-mail, you mentioned that your group > is working on implementation of mobile multicast in real appilication. Is it > based on MIPL stack? Is there any specific documents or guideline? I don't > think so. > > What is your guideline? I just want to know because I seem to have forgotten > big one. > > Cheers. > > > On 5/28/07, Tony wrote: > > > > > > >Message: 1 > > >Date: Thu, 24 May 2007 16:05:48 +0300 > > >From: "Decoy M" > > >Subject: Re: [multimob] What is multicast mobility? > > >To: "Alexandru Petrescu" > > >Cc: multimob@ietf.org > > >Message-ID: > > > <495d743d0705240605j77c47e9al39e696fdd399e4fd@mail.gmail.com> > > >Content-Type: text/plain; charset="iso-8859-1" > > > > > >On 5/24/07, Alexandru Petrescu wrote: > > >> > > >> Behcet Sarikaya wrote: > > >> > Hello Folks, Suresh, Thomas and I initiated this activity and now I > > >> > would like to propose a work plan and get your comments and > > >> > reactions. > > >> > > > >> > Item 1. Work on MLDv2 extensions. This work will concentrate on the > > >> > router part and will involve how to track per-host multicast listener > > >> > status and build per host context. Per host multicast listener > > >> > context block, etc. will be defined. > > >> > > >> Sorry, isn't MLDv2 router implementation already keeping track of > > >> listener status? > > > > > > > > >[Decoy] I think most of th routers doesnt keep track of the indivisual > > >multicast listeners but they just check whether some bosyis interested in > > >the multicast channel or not. So explicit Host tracking may not be > > required. > > >This requires table maintainance and other work as each and every Host > > >information needs to be stored and maintained. > > > > > >> Item 2. Base protocol MIPv6 extensions on handling multicast sessions > > >> > such as bandwidth inefficiency inherent in the home agent's > > >> > unicasting multicast packets through the tunnel. > > >> > > >> What could the HA do? Not unicast the multicast packets through the > > >> tunnel? > > HA can record the MN information and maintain MN's MLD state etc. > > Forwarding > > the multicast data through unicast tunnel is just one mobile multicast > > scheme. > > >> > Item 3. Handoff survival of local (at a foreign link) multicast > > >> > sessions will be taken up in the context of care-of address based > > >> > multicast group subscriptions. > > >> > > >> What's the influence of re-subscribing a new CoA upon each movement, on > > >> the infrastructure routing? > > If the New AR which MN attached has the multicast group state that MN > > subscribed, the > > multicast disruption time is short (100~200ms). while if New AR doesn't > > have the group > > states, it will take a long time to rejoin the groups. > > > > Our group is working on implementation of mobile multicast in real > > appilication recently. > > Welcome everyone to discuss. > > >> Alex > > >> > > >> > > >> ______________________________________________________________________ > > >> This email has been scanned by the MessageLabs Email Security System. > > >> For more information please visit http://www.messagelabs.com/email > > >> ______________________________________________________________________ > > >> > > >> _______________________________________________ > > >> multimob mailing list > > >> multimob@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/multimob > > >> > > >-------------- next part -------------- > > >An HTML attachment was scrubbed... > > >URL: > > http://www1.ietf.org/pipermail/multimob/attachments/20070524/e38c0354/attachment.html > > > > > >------------------------------ > > > > > >_______________________________________________ > > >multimob mailing list > > >multimob@ietf.org > > >https://www1.ietf.org/mailman/listinfo/multimob > > > > > > > > >End of multimob Digest, Vol 2, Issue 4 > > >************************************** > > > > > > > = = = = = = = = = = = = = = = = = = = = > > > > Tony > > guanjian8632@163.com > > 2007-05-28 > > +--------------------------------------+ > > | NGIRC, Beijing JiaoTong University | > > | BeiJing, China,100044 | > > | Http://www.njtu.edu.cn | > > +--------------------------------------+ > > > > > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www1.ietf.org/mailman/listinfo/multimob > > > > > > > -- > Internet Management Technology Lab, Sungkyunkwan University. > Jong-Hyouk Lee. > > #email: jonghyouk (at) gmail (dot) com > #webpage: http://www.hurryon.org > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://www1.ietf.org/pipermail/multimob/attachments/20070529/7a18fc90/attachment.html > > ------------------------------ > > _______________________________________________ > multimob mailing listmultimob@ietf.orghttps://www1.ietf.org/mailman/listinfo/multimob > > > End of multimob Digest, Vol 2, Issue 7 > ************************************** > > ------------------------------------------------------------------ > - > - > - > DISCLAIMER: > > This e-mail (including any attachments) may contain confidential > information. If you are not the intended recipient, you are hereby > notified that any dealing, review, distribution, printing, copying > or use of this e-mail is strictly prohibited. If you have received > this email in error, please notify the sender or MIMOS Berhad > immediately and delete the original message. Opinions, conclusions > and other information in this e-mail that do not relate to the > official business of MIMOS Berhad and/or its subsidiaries shall be > understood as neither given nor endorsed by MIMOS Berhad and/or its > subsidiaries and neither MIMOS Berhad nor its subsidiaries accepts > responsibility for the same. All liability arising from or in > connection with computer viruses and/or corrupted e-mails is > excluded to the fullest extent permitted by law. > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www1.ietf.org/mailman/listinfo/multimob > > -- Internet Management Technology Lab, Sungkyunkwan University. Jong-Hyouk Lee. #email: jonghyouk (at) gmail (dot) com #webpage: http://www.hurryon.org ------=_Part_3722_21232594.1180687526599 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dear colleague.
 
I agree with you. MIPL is a nice implementation for MIPv6. Absolutely, right. But, I just want to ask to Tony, what's the plan to implement for mobile multicast? I'm also interested in the implementation for mobile multicast.
 
Cheers.

 
On 5/29/07, Shariq Haseeb <shariq.haseeb@mimos.my> wrote:
Hi Jong-Hyouk,
 
I would just like to give my comments on Multicast and MIPL. I have done some work on mobile multicast with MIPL. What specific areas or applications of multicast are you interested in?
 
MIPL is a good implementation. I feel it is a very stable MIPv6 implementation.
 
Rgds,
Shariq

From: multimob-request@ietf.org
Sent: Tue 5/29/2007 3:11 PM
To: multimob@ietf.org
Subject: multimob Digest, Vol 2, Issue 7

 
Send multimob mailing list submissions to
	multimob@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/multimob
or, via email, send a message with subject or body 'help' to
	multimob-request@ietf.org

You can reach the person managing the list at
	multimob-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of multimob digest..."


Today's Topics:

   1. Re:  Re: multimob Digest, Vol 2, Issue 4 (Jong-Hyouk Lee)


----------------------------------------------------------------------

Message: 1
Date: Tue, 29 May 2007 16:11:35 +0900
From: "Jong-Hyouk Lee" <jonghyouk@gmail.com>
Subject: Re: [multimob] Re: multimob Digest, Vol 2, Issue 4
To: guanjian8632@163.com
Cc: multimob@ietf.org
Message-ID:
	<f54070070705290011k3b8c9a81j7674452195eee8a9@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Dear Tony.

I'd like to ask you. In the previous e-mail, you mentioned that your group
is working on implementation of mobile multicast in real appilication. Is it
based on MIPL stack? Is there any specific documents or guideline? I don't
think so.

What is your guideline? I just want to know because I seem to have forgotten
big one.

Cheers.


On 5/28/07, Tony <guanjian8632@163.com> wrote:
>
>
> >Message: 1
> >Date: Thu, 24 May 2007 16:05:48 +0300
> >From: "Decoy M" <decoy77@gmail.com>
> >Subject: Re: [multimob] What is multicast mobility?
> >To: "Alexandru Petrescu" <alexandru.petrescu@gmail.com>
> >Cc: multimob@ietf.org
> >Message-ID:
> >       <495d743d0705240605j77c47e9al39e696fdd399e4fd@mail.gmail.com
>
> >Content-Type: text/plain; charset="iso-8859-1"
> >
> >On 5/24/07, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
> >>
> >> Behcet Sarikaya wrote:
> >> > Hello Folks, Suresh, Thomas and I initiated this activity and now I
> >> > would like to propose a work plan and get your comments and
> >> > reactions.
> >> >
> >> > Item 1. Work on MLDv2 extensions. This work will concentrate on the
> >> > router part and will involve how to track per-host multicast listener
> >> > status and build per host context. Per host multicast listener
> >> > context block, etc. will be defined.
> >>
> >> Sorry, isn't MLDv2 router implementation already keeping track of
> >> listener status?
> >
> >
> >[Decoy] I think most of th routers doesnt keep track of the indivisual
> >multicast listeners but they just check whether some bosyis interested in
> >the multicast channel or not. So explicit Host tracking may not be
> required.
> >This requires table maintainance and other work as each and every Host
> >information needs to be stored and maintained.
> >
> >> Item 2. Base protocol MIPv6 extensions on handling multicast sessions
> >> > such as bandwidth inefficiency inherent in the home agent's
> >> > unicasting multicast packets through the tunnel.
> >>
> >> What could the HA do?  Not unicast the multicast packets through the
> >> tunnel?
>        HA can record the MN information and maintain MN's MLD state etc.
> Forwarding
> the multicast data through unicast tunnel is just one mobile multicast
> scheme.
> >> > Item 3. Handoff survival of local (at a foreign link) multicast
> >> > sessions will be taken up in the context of care-of address based
> >> > multicast group subscriptions.
> >>
> >> What's the influence of re-subscribing a new CoA upon each movement, on
> >> the infrastructure routing?
>   If the New AR which MN attached has the multicast group state that MN
> subscribed, the
> multicast disruption time is short (100~200ms). while if New AR doesn't
> have the group
> states, it will take a long time to rejoin the groups.
>
>        Our group is working on implementation of mobile multicast in real
> appilication recently.
> Welcome everyone to discuss.
> >> Alex
> >>
> >>
> >> ______________________________________________________________________
> >> This email has been scanned by the MessageLabs Email Security System.
> >> For more information please visit http://www.messagelabs.com/email
> >> ______________________________________________________________________
> >>
> >> _______________________________________________
> >> multimob mailing list
> >> multimob@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/multimob
> >>
> >-------------- next part --------------
> >An HTML attachment was scrubbed...
> >URL:
> http://www1.ietf.org/pipermail/multimob/attachments/20070524/e38c0354/attachment.html

> >
> >------------------------------
> >
> >_______________________________________________
> >multimob mailing list
> >multimob@ietf.org
> >https://www1.ietf.org/mailman/listinfo/multimob
> >
> >
> >End of multimob Digest, Vol 2, Issue 4
> >**************************************
> >
>
> = = = = = = = = = = = = = = = = = = = =
>
> Tony
> guanjian8632@163.com
> 2007-05-28
> +--------------------------------------+
> |      NGIRC, Beijing JiaoTong University      |
> |      BeiJing, China,100044                           |
> |      Http://www.njtu.edu.cn                          |
> +--------------------------------------+
>
>
> _______________________________________________
> multimob mailing list
> multimob@ietf.org
> https://www1.ietf.org/mailman/listinfo/multimob
>
>


-- 
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www1.ietf.org/pipermail/multimob/attachments/20070529/7a18fc90/attachment.html


------------------------------

_______________________________________________
multimob mailing list
multimob@ietf.org
https://www1.ietf.org/mailman/listinfo/multimob


End of multimob Digest, Vol 2, Issue 7
**************************************

------------------------------------------------------------------
-
-
-
DISCLAIMER:

This e-mail (including any attachments) may contain confidential
information. If you are not the intended recipient, you are hereby
notified that any dealing, review, distribution, printing, copying
or use of this e-mail is strictly prohibited. If you have received
this email in error, please notify the sender or MIMOS Berhad
immediately and delete the original message. Opinions, conclusions
and other information in this e-mail that do not relate to the
official business of MIMOS Berhad and/or its subsidiaries shall be
understood as neither given nor endorsed by MIMOS Berhad and/or its
subsidiaries and neither MIMOS Berhad nor its subsidiaries accepts
responsibility for the same. All liability arising from or in
connection with computer viruses and/or corrupted e-mails is
excluded to the fullest extent permitted by law.


_______________________________________________
multimob mailing list
multimob@ietf.org
https://www1.ietf.org/mailman/listinfo/multimob




--
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org ------=_Part_3722_21232594.1180687526599-- --===============1588649248== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob --===============1588649248==-- From multimob-bounces@ietf.org Fri Jun 08 15:31:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwkB4-0003lo-NA; Fri, 08 Jun 2007 15:31:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwkB2-0003lS-QV for multimob@ietf.org; Fri, 08 Jun 2007 15:31:16 -0400 Received: from web84104.mail.mud.yahoo.com ([68.142.206.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwkB1-0006u0-AW for multimob@ietf.org; Fri, 08 Jun 2007 15:31:16 -0400 Received: (qmail 52128 invoked by uid 60001); 8 Jun 2007 19:31:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=Lhcn1SAwYepKi8lhO9SQj7VUJ+N9Y0efIbbBpRoz53ogHVOSRQspiJw1BgnA2tAFZfFnIQfKkYd3o8hVtNva2sNZTkR4RvV0H3VaklRLZcxTGgZny+aMtPLOkSgVM4o5Imiw1uM0EKsh4XPtLGcsy7gMyZuCX9GWkO6vTHD2sCk=; X-YMail-OSG: mdzPrEUVM1k6Fru.WNbtWjbx36aB1QMpVJTCy7seE30vZaff7D2pZmOT9_67zbg_QIsMYvfHtDPln8CHNW4_.zok7lsClyURm8xAWDPewvaB92iGN8Y- Received: from [206.16.17.212] by web84104.mail.mud.yahoo.com via HTTP; Fri, 08 Jun 2007 12:31:14 PDT X-Mailer: YahooMailRC/651.23.1 YahooMailWebService/0.7.41.14 Date: Fri, 8 Jun 2007 12:31:14 -0700 (PDT) From: Behcet Sarikaya To: Brian Haberman , Julien Laganier MIME-Version: 1.0 Message-ID: <813673.34356.qm@web84104.mail.mud.yahoo.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: multimob@ietf.org, INT Area Subject: [multimob] Re: [Int-area] SeND & CGA Extensions BOF X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0290837683==" Errors-To: multimob-bounces@ietf.org --===============0290837683== Content-Type: multipart/alternative; boundary="0-674350378-1181331074=:34356" --0-674350378-1181331074=:34356 Content-Type: text/plain; charset=ascii Hi Brian, Julien, ----- Original Message ---- From: Brian Haberman To: Julien Laganier Cc: INT Area ; int-area@lists.ietf.org Sent: Friday, June 8, 2007 9:13:50 AM Subject: Re: [Int-area] SeND & CGA Extensions BOF Hi Julien, Julien Laganier wrote: > Hi Marcelo, others, > > How about including work on extensions to secure > Multicast Listener Discovery Version 2 (MLDv2) for > IPv6, along the same lines that what was done to > secure Neighbor Discovery: > > 1. protection against spoofing of multicast listener > report messages in which a rogue node unsubscribe its > target from receiving multicast traffic. This type of attack is mitigated by the MLD state machine. When a router receives a Report that signals no more interest in a particular group it first sends out a group-specific query to ensure that interest does not exist. When that query is sent, the target node will respond that it is still interested. > > 2. protection against spoofing of multicast Listener > query messages in which a rogue node with a lower IPv6 > address than the current querier will cause querier > duties to be assigned to the rogue node. This would be useful in my opinion. Regards, Brian [behcet] I think these (or this) issues need better be handled in multicast related WG in int area, magma is one. We recently started multimob mailing list (cc'ed), if the above issue is likely to arise in mobile environments, multimob could also be considered. Regards, Behcet _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area --0-674350378-1181331074=:34356 Content-Type: text/html; charset=ascii
Hi Brian, Julien,

----- Original Message ----
From: Brian Haberman <brian@innovationslab.net>
To: Julien Laganier <julien.IETF@laposte.net>
Cc: INT Area <int-area@ietf.org>; int-area@lists.ietf.org
Sent: Friday, June 8, 2007 9:13:50 AM
Subject: Re: [Int-area] SeND & CGA Extensions BOF

Hi Julien,

Julien Laganier wrote:
> Hi Marcelo, others,
>
> How about including work on extensions to secure
> Multicast Listener Discovery Version 2 (MLDv2) for
> IPv6, along the same lines that what was done to
> secure Neighbor Discovery:
>
> 1. protection against spoofing of multicast listener
> report messages in which a rogue node unsubscribe its
> target from receiving multicast traffic.

This type of attack is mitigated by the MLD state machine.  When a
router receives a Report that signals no more interest in a particular
group it first sends out a group-specific query to ensure that interest
does not exist.  When that query is sent, the target node will respond
that it is still interested.

>
> 2. protection against spoofing of multicast Listener
> query messages in which a rogue node with a lower IPv6
> address than the current querier will cause querier
> duties to be assigned to the rogue node.  

This would be useful in my opinion.

Regards,
Brian

[behcet] I think these (or this) issues need better be handled in multicast related WG in int area, magma is one. We recently started multimob mailing list (cc'ed), if the above issue is likely to arise in mobile environments, multimob could also be considered.

Regards,

Behcet

_______________________________________________
Int-area mailing list
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area

--0-674350378-1181331074=:34356-- --===============0290837683== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob --===============0290837683==--