FYI.
Regards,
Thomas Trede
----- Original Message -----
From: "Vida Rolland" <Rolland.Vida(a)lip6.fr>
To: <ipng(a)sunroof.eng.sun.com>; <ssm-interest(a)external.cisco.com>; "Supratik
Bhattacharyya" <supratik(a)sprintlabs.com>
Sent: Wednesday, November 08, 2000 6:30 PM
Subject: MLDv3 - Internet Draft
> Dear All,
>
> The revised IPng Working Group Charter published on the 5th of October
> on the mailing list of the IPng WG contained a call for contribution on
> "Extending MLD to include functionality of IGMPv3".
>
> Here is the abstract of an Internet Draft proposal, called "Multicast
> Listener Discovery Version 3 (MLDv3) for IPv6"
> (<draft-vida-mld-v3-00.txt>)
>
> *************
> Abstract:
>
> This document specifies Version 3 of the Multicast Listener Discovery
> protocol, MLDv3. MLD is the protocol used by an IPv6 router to
> discover the presence of multicast listeners (that is, nodes wishing
> to receive multicast packets) on its directly attached links, and to
> discover specifically which multicast addresses are of interest to
> those neighboring nodes.
>
> MLDv3 is derived from version 3 of IPv4's Internet Group Management
> Protocol, IGMPv3. Compared to the previous version, MLDv3 adds
> support for "source filtering", that is, the ability for a node to
> report interest in listening to packets *only* from specific source
> addresses, or from *all but* specific source addresses, sent to a
> particular multicast address. That information may be used by
> multicast routing protocols to avoid delivering multicast packets
> from specific sources to links where there are no interested
> listeners. When compared to IGMPv3, one important difference
> to note is that MLDv3 uses ICMPv6 (IP Protocol 58) message
> types, rather than IGMP (IP Protocol 2) message types.
>
> ************
>
> The full text of the draft can be found at:
> http://www-rp.lip6.fr/~vida/draft-vida-mld-v3-00.txt
>
> We welcome any comments or suggestions on the text.
>
> Best regards,
>
> Rolland Vida,
> LIP6, Paris, France.
>
> -----------------------------------------------------------------------
> "Not everything that can be counted counts, and not everything that
> counts can be counted. " - Albert Einstein
> Rolland Vida
> Universite Paris VI "Pierre et Marie Curie" tel: +33 (0)144 277 126
> Laboratoire LIP6 - CNRS, C669 fax: +33 (0)144 277 495
> 8, Rue de Capitaine Scott, 75015, Paris mailto:vida@rp.lip6.fr
> -----------------------------------------------------------------------
>
>
>
>
>
>
> --------------------------------------------------------------------
> 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 majordomo(a)sunroof.eng.sun.com
> --------------------------------------------------------------------
>
FYI.
Regards,
Thomas Trede
----- Original Message -----
From: <Internet-Drafts(a)ietf.org>
To: <IETF-Announce: ;>
Cc: <ipng(a)sunroof.eng.sun.com>
Sent: Wednesday, November 08, 2000 11:59 AM
Subject: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-02.txt
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the IPNG Working Group of the IETF.
>
> Title : Advanced Sockets API for IPv6
> Author(s) : R. Stevens, M. Thomas, E. Nordmark
> Filename : draft-ietf-ipngwg-rfc2292bis-02.txt
> Pages : 74
> Date : 07-Nov-00
>
> A separate specification [RFC-2553] contain changes to the sockets
> API to support IP version 6. Those changes are for TCP and UDP-based
> applications and will support most end-user applications in use
> today: Telnet and FTP clients and servers, HTTP clients and servers,
> and the like.
> But another class of applications exists that will also be run under
> IPv6. We call these 'advanced' applications and today this includes
> programs such as Ping, Traceroute, routing daemons, multicast routing
> daemons, router discovery daemons, and the like. The API feature
> typically used by these programs that make them 'advanced' is a raw
> socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge
> of the packet header formats used by these protocols. To provide
> portability for applications that use raw sockets under IPv6, some
> standardization is needed for the advanced API features.
> There are other features of IPv6 that some applications will need to
> access: interface identification (specifying the outgoing interface
> and determining the incoming interface) and IPv6 extension headers
> that are not addressed in [RFC-2553]: The Routing header (source
> routing), Hop-by-Hop options, and Destination options. This document
> provides API access to these features too.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-02.txt
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-ipngwg-rfc2292bis-02.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv(a)ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-02.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility. To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command. To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader. Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
