- ipv6-wg - mailman.ripe.net

WG: I-D ACTION:draft-kempf-ipng-netaccess-threats-00.txt
by Thomas Trede 27 Nov '01

27 Nov '01

FYI. Regards, Thomas Trede -----Ursprï¿½ngliche Nachricht----- Von: owner-ipng(a)sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]Im Auftrag von Internet-Drafts(a)ietf.org Gesendet: Montag, 26. November 2001 12:17 An: IETF-Announce: Cc: ipng(a)sunroof.eng.sun.com Betreff: I-D ACTION:draft-kempf-ipng-netaccess-threats-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Threat Analysis for IPv6 Public Multi-Access Links Author(s) : J. Kempf, E. Nordmark Filename : draft-kempf-ipng-netaccess-threats-00.txt Pages : 7 Date : 21-Nov-01 The Mobile IP Working Group has been conducting a threat analysis for the purpose of securing specific Mobile IPv6 mechanisms. In the process of conducting the analysis, threats were identified that are not specific to Mobile IP but that are amplified by the nature of mobility. These threats are likely to be more or less of an issue within any Public Multi-Access network, regardless of whether mobility is involved. This document discusses threats associated with Public Multi-Access links in IPv6. The document covers non- Mobile IP specific threats uncovered by the Mobile IPv6 study, threats raised in the IPv6 Neighbor Discovery and Stateless Address Autoconfiguration RFCs that have yet to be adequately addressed, and new threats that have not previously been identified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kempf-ipng-netaccess-threats-00.tx t To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-kempf-ipng-netaccess-threats-00.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-kempf-ipng-netaccess-threats-00.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. ENCODING mime FILE /internet-drafts/draft-kempf-ipng-netaccess-threats-00.txt

1 0

WG: I-D ACTION:draft-huitema-ipngwg-dialondemand-00.txt
by Thomas Trede 19 Nov '01

19 Nov '01

FYI. Regards, Thomas Trede -----Ursprï¿½ngliche Nachricht----- Von: owner-ipng(a)sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]Im Auftrag von Internet-Drafts(a)ietf.org Gesendet: Montag, 19. November 2001 14:31 An: IETF-Announce: Cc: ipng(a)sunroof.eng.sun.com Betreff: I-D ACTION:draft-huitema-ipngwg-dialondemand-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Dial-up on Demand Author(s) : C. Huitema Filename : draft-huitema-ipngwg-dialondemand-00.txt Pages : 12 Date : 16-Nov-01 In an IPv6 home network, there is a possibility that the residential gateway, learns a different IPv6 prefix after each dial-up; attempts to communicate using old address would thus fail. This implies that we should not attempt to trigger dial-up by simply sending the first packet of a connection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-huitema-ipngwg-dialondemand-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-huitema-ipngwg-dialondemand-00.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-huitema-ipngwg-dialondemand-00.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. ENCODING mime FILE /internet-drafts/draft-huitema-ipngwg-dialondemand-00.txt

1 0

Problem statement for transit/exchange only IPv6 address space
by Janos Mohacsi 14 Nov '01

14 Nov '01

Dear All, Sorry for cross posting this message to more than one IPv6 related mailing list, but I think IPv6 community should prepare with some position to the transit/exchange only providers. I have seen the excellent presentation from Mirjam Kï¿½hne from RIPE-39 about IPv6 exchange proviers, but then I have not seen any discussion. My goal with this problem statement to increase the debate and hopefully reach some consensus about the problem. The problem statement is rather long.... Sorry about that. Kind Regards, Janos Mohacsi Problem statement for transit/exchange only IPv6 address space: The current Proposed TLA and NLA Assignment Rules (RFC 2450) and IPv6 Aggregatable Global Unicast Address Format (RFC 2374) is not particularly supporting addressing long haul transit providers or exchange providers. As RFC2374 states: "While this address format is designed to support exchange-based aggregation (in addition to current provider-based aggregation) it is not dependent on exchanges for it's overall route aggregation properties. It will provide efficient route aggregation with only provider-based aggregation." What is the current proposed solution to obtain IPv6 addresses for long-haul IPv6 transit providers or IPv6 exchange providers? To better understand the case I try to explain the problem more thoroughly. Let suppose the following situation: There is a long-haul ipv6 transit provider call it X. X is providing IPv6 transit or exchange service for ISPs Y1, Y2,....Yn. But X provide only IPv6 address assignment service for few customers of Yi, let say only for 4-5 customers, for one of the following reasons: 1. Most Y1,Y2, ... Yn has already production IPv6 subTLA 2. X company profile does not contain running local IP registry. 3. other reason X operates its offices in the area of Yi. For office purpose X can obtain IPv6 address from Yi. For IPv6 transit provision X needs an IPv6 address, but probably not /35 addresses, but /44 is enough, even if the transit network is quite extensive and geographically large. Scenario 1: X request address for its transit network from Yi, since his office is in the area of Yi. They get /44 from Yi (it must be difficult according to the current NLA allocation rules). X is implementing transit service and establishes private or public peering with ISP Z1, Z2, ... Zn and of course ISP Y1, Y2, ... Yn. To help the network management X implement and run some monitoring tools on the network near to monitored equipment. X can access its network, the involved network was network Yi. They are happy with the monitoring tools and X wants to share some results with Zk and Yj. Since the strict aggregation network addresses: of X-transit_network will be reacheable via Yi peering of Zk and Yj, not via peering of X-Zk and X-Yj that would be preferred. X can advertise more specific routes Zk and Yj, but this way X pollutes with non really aggregated entries the routing table of Zk and Yj. If they implement a really strict aggregation scheme then these more specific routes are discarded. How can X solve the problem? What happens if X wants to change provider from Yi to Yj? What happens if X has more than office one near to Yi and the other Yj? Which one should be used? Or some kind of multihoming should be used? Scenario 2: X request address (a subTLA) for its transit network from Regional IP Registry. X implementing IPv6 transit service and also network monitoring as before, but he does not allocate addresses just for few ISP Y. This somehow violates the current registration policy, since X does not fulfill all the 5.1 requirements of RFC 2450 and the corresponding RIR IPv6 allocation policy documents. There is no problem with accessing the services via the preferred peering since aggregation is done in X based on subTLA. Is this the current recommended solution? Scenario 3: X request address for office purpose only from Yi, and for the network they use site local address. The public and private BGP peering is quite problematical in this case, since some routers does not allow using local type IPv6 addresses in BGP peering. Providing the monitoring services can be also difficult, since monitoring tools cannot be reached outside of X transit network. This solution is not really acceptable. Or you have some other idea?

3 2

WG: I-D ACTION:draft-park-host-based-mcast-00.txt
by Thomas Trede 14 Nov '01

14 Nov '01

FYI. Regards, Thomas Trede -----Ursprï¿½ngliche Nachricht----- Von: owner-ipng(a)sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]Im Auftrag von Internet-Drafts(a)ietf.org Gesendet: Mittwoch, 14. November 2001 13:01 An: IETF-Announce: Cc: ipng(a)sunroof.eng.sun.com Betreff: I-D ACTION:draft-park-host-based-mcast-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Host-based IPv6 Multicast Addresses Allocation Author(s) : J. Park et al. Filename : draft-park-host-based-mcast-00.txt Pages : 6 Date : 13-Nov-01 This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for sing interface-ID to allocate multicast addresses. When the link-local unicast address is configured at each interface of host, interface ID is uniquely determined. By delegating multicast addresses at the same time as interface ID, each host can identify their multicast addresses automatically at Layer 1 without needing to run an intra- or inter-domain allocation protocol in the serverless environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-park-host-based-mcast-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-park-host-based-mcast-00.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-park-host-based-mcast-00.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. ENCODING mime FILE /internet-drafts/draft-park-host-based-mcast-00.txt

1 0

WG: I-D ACTION:draft-ietf-vrrp-ipv6-spec-00.txt
by Thomas Trede 29 Oct '01

29 Oct '01

FYI. Regards, Thomas Trede -----Ursprungliche Nachricht----- Von: owner-ipng(a)sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]Im Auftrag von by way of Bob Hinden <hinden(a)iprg.nokia.com> Gesendet: Freitag, 26. Oktober 2001 16:38 An: ipng(a)sunroof.eng.sun.com Betreff: I-D ACTION:draft-ietf-vrrp-ipv6-spec-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual Router Redundancy Protocol Working Group of the IETF. Title : Virtual Router Redundancy Protocol for IPv6 Author(s) : B. Hinden Filename : draft-ietf-vrrp-ipv6-spec-00.txt Pages : 31 Date : 24-Oct-01 This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv6. It is version three (3) of the protocol. It is based on the original version of VRRP (version 2) for IPv4 that is defined in RFC2338. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-vrrp-ipv6-spec-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-vrrp-ipv6-spec-00.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-vrrp-ipv6-spec-00.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. Content-Type: text/plain Content-ID: <20011024104225.I-D(a)ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vrrp-ipv6-spec-00.txt <ftp://ftp.ietf.org/internet-drafts/draft-ietf-vrrp-ipv6-spec-00.txt> -------------------------------------------------------------------- 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 --------------------------------------------------------------------

1 0

WG: RFC 3146 on IPv6 Packets over IEEE 1394 Networks
by Thomas Trede 26 Oct '01

26 Oct '01

FYI. Regards, Thomas Trede -----Ursprï¿½ngliche Nachricht----- Von: owner-ipng(a)sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]Im Auftrag von RFC Editor Gesendet: Freitag, 26. Oktober 2001 02:09 An: IETF-Announce: Cc: rfc-ed(a)ISI.EDU; ipng(a)sunroof.eng.sun.com Betreff: RFC 3146 on IPv6 Packets over IEEE 1394 Networks A new Request for Comments is now available in online RFC libraries. RFC 3146 Title: Transmission of IPv6 Packets over IEEE 1394 Networks Author(s): K. Fujisawa, A. Onoe Status: Standards Track Date: October 2001 Mailbox: fujisawa(a)sm.sony.co.jp, onoe(a)sm.sony.co.jp Pages: 8 Characters: 16513 SeeAlso/Updates/Obsoletes: None I-D Tag: draft-ietf-ipngwg-1394-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3146.txt This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. This document is the product of the IPNG Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST(a)IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST(a)RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info(a)RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info(a)RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager(a)RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR(a)RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. RETRIEVE: rfc DOC-ID: rfc3146

1 0

NEW mailing lists for global IPv6 address policy
by Mirjam Kuehne 18 Oct '01

18 Oct '01

Dear Colleagues, Please find below information about a new mailing list set up to discuss IPv6 address policy on a global level. Kind Regards, Mirjam Kuhne RIPE NCC -------------------------------------------------- * GLOBAL DEVELOPMENT OF REVISED IPv6 ADDRESS POLICY A new mailing list has been established to co-ordinate global policy discussions on the development of a revised IPv6 addressing policy to replace the "Provisional IPv6 assignment and allocation policy document". The list name is <global-v6(a)lists.apnic.net>. Although this list is hosted by APNIC, it is open to all members of the global Internet community with an interest in IPv6 address policy. Subscription information is available at: http://www.apnic.net/net_comm/lists/ Archives of discussions are available at: http://www.apnic.net/mailing-lists/global-v6 --------------- The RIRs encourage all interested parties to subscribe to this list and contribute to the development of important global address policy.

1 0

IPv6 Network Plans (Forcasting)
by Dave Pratt 18 Oct '01

18 Oct '01

Hiya Folks, I would like to elaborate on a comment made at the end of the LIR/IPv6 session in Prague about the ability of IPv6 address space requesters to forecast their address requirements. These suggestions probably might not make it into the provisional policy, but should be considered for later policy. A large ISP, probably global, and certainly national, could build its entire infrastructure with a single /48 network block. For example this would allow 256 "locations", each with 256 networks, each with more hosts than ants on this planet.... With the popular /127 for point-point connections even customer lines can be accomodated. Accordingly, the only driver for longer prefixes would seem to be the /48 customer networks. How will applicants for IPv6 address allocations quantify these networks ? The only way I can see is from very early marketing forcasts. In the past RIPE have viewed marketing forecasts with a lot of suspicion (quite rightly). However, unless RIPE issue a "one size fits all" prefix they may have to base allocations on these marketing forecasts. One thing however can be relatively easily determined, and that is "whether an applicant has ANY customers". For those LIR WITHOUT any customers, we could allocate a /48 and even large multinational corporations would have plenty of addresses (see second paragraph above again). For those LIR WITH customers, we should be much more generous because we cannot accurately judge needs from marketing forecasts. Assuming a HD ratio of 0.8, then a moderately successful city carrier LIR with 100,000 DSL or Cable customers (each requiring a /48) will qualify for more than a /28 allocation. Do we want such LIRs to come back and ask for a second route (in the global routing table) ? Conclusion: 1. We should consider allocating a /48 to LIR without any customers as this is plenty. 2. Even a /28 would result in considerable numbers of followup requests if cable/DSL customers (mass users) get /48. Opinions, Comments, Concensus ? Cheers Dave

4 5

WG: I-D ACTION:draft-ietf-ipngwg-default-addr-select-06.txt
by Thomas Trede 16 Oct '01

16 Oct '01

FYI. Regards, Thomas Trede -----Ursprï¿½ngliche Nachricht----- Von: owner-ipng(a)sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]Im Auftrag von Internet-Drafts(a)ietf.org Gesendet: Montag, 1. Oktober 2001 13:04 An: IETF-Announce: Cc: ipng(a)sunroof.eng.sun.com Betreff: I-D ACTION:draft-ietf-ipngwg-default-addr-select-06.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 : Default Address Selection for IPv6 Author(s) : R. Draves Filename : draft-ietf-ipngwg-default-addr-select-06.txt Pages : 22 Date : 28-Sep-01 This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all IPv6 implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common framework, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the framework allows the destination address selection algorithm to consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-default-addr-select-06 .txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-default-addr-select-06.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-default-addr-select-06.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. ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-default-addr-select-06.txt

1 0

WG: I-D ACTION:draft-ietf-ipngwg-uni-based-mcast-03.txt
by Thomas Trede 16 Oct '01

16 Oct '01

FYI. Regards, Thomas Trede -----Ursprï¿½ngliche Nachricht----- Von: owner-ipng(a)sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]Im Auftrag von Internet-Drafts(a)ietf.org Gesendet: Montag, 15. Oktober 2001 13:01 An: IETF-Announce: Cc: ipng(a)sunroof.eng.sun.com Betreff: I-D ACTION:draft-ietf-ipngwg-uni-based-mcast-03.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 : Unicast-Prefix-based IPv6 Multicast Addresses Author(s) : B. Haberman, D. Thaler Filename : draft-ietf-ipngwg-uni-based-mcast-03.txt Pages : 6 Date : 12-Oct-01 This specification defines an extension to the multicast addressing architecture of the IP Version 6 protocol. The extension presented in this document allows for unicast-prefix-based allocation of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-uni-based-mcast-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-uni-based-mcast-03.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-uni-based-mcast-03.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. ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-uni-based-mcast-03.txt

1 0