The IESG | 24 Feb 2005 21:05
Picon
Favicon

WG Action: Conclusion of Inter-Domain Multicast Routing (idmr)

The Inter-Domain Multicast Routing (idmr) working group in the Routing Area 
has concluded.

The IESG contact persons are Bill Fenner and Alex Zinin. 

The mailing list will remain active.

_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

Bill Fenner | 16 Feb 2005 18:01
Picon

I-D ACTION:draft-fenner-traceroute-ipm-01.txt


----- Begin forwarded message:

From: Internet-Drafts <at> ietf.org
Subject: I-D ACTION:draft-fenner-traceroute-ipm-01.txt
Date: Wed, 16 Feb 2005 09:59:49 -0500
To: i-d-announce <at> ietf.org
Reply-to: internet-drafts <at> ietf.org

	Title		: A 'traceroute' facility for IP Multicast.
	Author(s)	: B. Fenner, et al.
	Filename	: draft-fenner-traceroute-ipm-01.txt
	Pages		: 25
	Date		: 2005-2-15
	
This draft describes the IGMP multicast traceroute facility.
Unlike unicast traceroute, multicast traceroute requires a special
packet type and implementation on the part of routers.  This speci-
fication describes the required functionality in multicast routers,
as well as how management applications can use the new router func-
tionality.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-fenner-traceroute-ipm-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.
(Continue reading)

Bill Fenner | 11 Feb 2005 18:07
Picon

Re: Latest status of Multicast Traceroute


>What is status of multicast traceroute, both the Internet-Draft and mtrace? 

I just resubmitted the latest Internet-Draft.

>Is the effort to progress draft abandoned or transformed into other life
>form?  

It fell by the wayside because we never managed to finish addressing
concerns over whether or not hosts should be allowed to send these
packets - when we were initially ready to publish the spec, smurf
and other packet amplification attacks were getting popular and with
the "return this packet to arbitrary IP address" request, mtrace
could fall in that class.

The tension between wanting to allow arbitrary users to use the tool
(just like with unicast traceroute) and wanting to restrict it for
security meant that we never made any progress.

  Bill

Chen, Weijing | 3 Feb 2005 16:30
Picon

Latest status of Multicast Traceroute

What is status of multicast traceroute, both the Internet-Draft and mtrace?  Is the effort to progress draft abandoned or transformed into other life form?

 

Thanks.

 

 

--

Weijing Chen

 

Bill Fenner | 18 Aug 2004 20:06
Picon

Re: IGMP checksum question


Are you sure the IP length is extended, or are you just seeing padding
in layer 2?

I've never seen an implementation that calculates the checksum (either
for transmitting or receiving) over a subset of the IP length.

  Bill

Koen Vermeulen | 4 Aug 2004 13:02
Picon
Picon

IGMP checksum question

Hello,

In RFC3376 (IGMPv3) is stated that the IGMP checksum is calculated over 
the whole IGMP
packet, which is the total length of the IP payload. Using the full 
length of the IP payload makes
sense according to me because there exists no length field in the IGMP 
header.

During testing I however saw some tools which have a different way of 
calculating the checksum.
I recently saw a tool which sometimes pads the IP packet to 64 bytes 
(don't ask me why this is
done) and instead of calculating the checksum over the full IP payload, 
it only calculates this checksum
over the length of the IGMP information inside the IP packet.

I initially thought this was a bug of the tool, but when I was sending 
these packets to the ethereal
tool, I could see that ethereal interpreted this checksum as correct.

Is there anyone who is also having some experience with this kind of 
problem and knows which
approached is followed in the 'world'?

Thanks,
Koen

GuoFeng | 15 Jul 2004 15:22
Favicon

regarding IGMPv3 state transition

Hi all,
    I have two questions regarding IGMPv3 below. Please help me to find
the answers, TIA. The detailed RFC info is listed in the end of this
email.
>6.4.2. Reception of Filter-Mode-Change and Source-List-Change Records
>EXCLUDE (X,Y)  TO_EX (A)    EXCLUDE (A-Y,Y*A)       (A-X-Y)=Group Timer
>                                                    Delete (X-A)
>                                                    Delete (Y-A)
>                                                    Send Q(G,A-Y)
>                                                    Group Timer=GMI	
Question 1. Why the result is EXCLUDE (A-Y,Y*A), not EXCLUDE
(X+A-Y,Y*A). Since there might be hosts are interested in X-(A-Y).

Question 2. Why "(A-X-Y)=Group Timer"? Since A-X-Y is a subset of A-Y,
later it will be lowered to LMQT when "Send Q(G,A-Y)". 

Thanks again,
Guo Feng

-----excerpted from RFC 3376 IGMPv3---------
6.4.2. Reception of Filter-Mode-Change and Source-List-Change Records

   When a change in the global state of a group occurs in a system, the
   system sends either a Source-List-Change Record or a Filter-Mode-
   Change Record for that group.  As with Current-State Records, routers
   must act upon these records and possibly change their own state to
   reflect the new desired membership state of the network.

   Routers must query sources that are requested to be no longer
   forwarded to a group.  When a router queries or receives a query for
   a specific set of sources, it lowers its source timers for those
   sources to a small interval of Last Member Query Time seconds.  If
   group records are received in response to the queries which express
   interest in receiving traffic from the queried sources, the
   corresponding timers are updated.

   Similarly, when a router queries a specific group, it lowers its
   group timer for that group to a small interval of Last Member Query
   Time seconds.  If any group records expressing EXCLUDE mode interest
   in the group are received within the interval, the group timer for
   the group is updated and the suggestion to the routing protocol to
   forward the group stands without any interruption.

   During a query period (i.e., Last Member Query Time seconds), the
   IGMP component in the router continues to suggest to the routing
   protocol that it forwards traffic from the groups or sources that it
   is querying.  It is not until after Last Member Query Time seconds
   without receiving a record expressing interest in the queried group
   or sources that the router may prune the group or sources from the
   network.

Cain, et. al.               Standards Track                    [Page 31]

RFC 3376                         IGMPv3                     October 2002

   The following table describes the changes in group state and the
   action(s) taken when receiving either Filter-Mode-Change or Source-
   List-Change Records.  This table also describes the queries which are
   sent by the querier when a particular report is received.

   We use the following notation for describing the queries which are
   sent.  We use the notation 'Q(G)' to describe a Group-Specific Query
   to G.  We use the notation 'Q(G,A)' to describe a Group-and-Source
   Specific Query to G with source-list A.  If source-list A is null as
   a result of the action (e.g., A*B) then no query is sent as a result
   of the operation.

   In order to maintain protocol robustness, queries sent by actions in
   the table below need to be transmitted [Last Member Query Count]
   times, once every [Last Member Query Interval].

   If while scheduling new queries, there are already pending queries to
   be retransmitted for the same group, the new and pending queries have
   to be merged.  In addition, received host reports for a group with
   pending queries may affect the contents of those queries.  Section
   6.6.3 describes the process of building and maintaining the state of
   pending queries.

Router State   Report Rec'd New Router State        Actions
------------   ------------ ----------------        -------

INCLUDE (A)    ALLOW (B)    INCLUDE (A+B)           (B)=GMI

INCLUDE (A)    BLOCK (B)    INCLUDE (A)             Send Q(G,A*B)

INCLUDE (A)    TO_EX (B)    EXCLUDE (A*B,B-A)       (B-A)=0
                                                    Delete (A-B)
                                                    Send Q(G,A*B)
                                                    Group Timer=GMI

INCLUDE (A)    TO_IN (B)    INCLUDE (A+B)           (B)=GMI
                                                    Send Q(G,A-B)

EXCLUDE (X,Y)  ALLOW (A)    EXCLUDE (X+A,Y-A)       (A)=GMI

EXCLUDE (X,Y)  BLOCK (A)    EXCLUDE (X+(A-Y),Y)     (A-X-Y)=Group Timer
                                                    Send Q(G,A-Y)

EXCLUDE (X,Y)  TO_EX (A)    EXCLUDE (A-Y,Y*A)       (A-X-Y)=Group Timer
                                                    Delete (X-A)
                                                    Delete (Y-A)
                                                    Send Q(G,A-Y)
                                                    Group Timer=GMI
Bryan McLaughlin (brmclaug | 28 Jun 2004 16:47
Picon
Favicon

RE: IGMP Proxy RFC Status

Rob Magma working group has this
 
draft-ietf-magma-igmp-proxy-06.txt
 
Bryan



 
Hello,

Did "IGMP-based Multicast Forwarding ("IGMP Proxying")", draft-ietf-idmr-igmp-proxy-01.txt, become a standard?

Regards,
Rob Parsons

Rob Parsons | 28 Jun 2004 13:24
Picon

IGMP Proxy RFC Status

Hello,

Did "IGMP-based Multicast Forwarding ("IGMP Proxying")", draft-ietf-idmr-igmp-proxy-01.txt, become a standard?

Regards,
Rob Parsons

The IESG | 11 Jun 2004 16:55
Picon
Favicon

Last Call: 'Distance Vector Multicast Routing Protocol' to Proposed Standard

The IESG has received a request from the Inter-Domain Multicast Routing WG to 
consider the following documents:

- 'Distance Vector Multicast Routing Protocol '
   <draft-ietf-idmr-dvmrp-v3-11.txt> as a Proposed Standard
- 'Distance Vector Multicast Routing Protocol Applicability Statement '
   <draft-ietf-idmr-dvmrp-v3-as-01.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2004-06-25.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-idmr-dvmrp-v3-11.txt
http://www.ietf.org/internet-drafts/draft-ietf-idmr-dvmrp-v3-as-01.txt

_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

황선영 | 20 May 2004 07:25

Question about IGMPv3 compatibility

Hello,
 
I have a question about IGMPv3.
 
If an interface receives a leave message for a group G and G's Group Compatibility Mode is IGMPv3,
then the Group Compatibility Mode should be changed to IGMPv2 ?

Gmane