- ipv6-wg - mailman.ripe.net

Draft agenda (v2) for IPv6 working group RIPE41
by David Kessens 03 Jan '02

03 Jan '02

Hi, Below follows the second draft agenda for the ipv6 wg. We will only meet for one meeting slot for the regular working group session due to all the attention for ipv6 in other (joint) sessions. As you can see, we don't have that many agenda topics yet. I would very much welcome your input on other interesting topics that you might want to volunteer yourself or somebody else for. There will be a separate session on ipv6 allocation policy where we will discuss the new draft on global ipv6 allocation policies. A draft proposal was recently posted to the global list for ipv6 policy discussions (<global-v6-request(a)apnic.net>). An agenda for this session will be published later. There will also be a session on RPSL and ipv6 in cooperation with the routing working group. This session will be coordinated by the routing working group chairperson Joachim Schmitz. Thanks, David K. --- Draft agenda (v2) for the IPv6 Working Group Meeting RIPE41, Amsterdam A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of the 6bone (David Kessens) C. Global IPv6 routing table status (Gert Doering) D. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) Z. AOB ---

2 1

Draft agenda (v1) for IPv6 working group RIPE41
by David Kessens 20 Dec '01

20 Dec '01

Hi, Below follows the first draft agenda for the ipv6 wg. We will only meet for one meeting slot for the regular working group session due to all the attention for ipv6 in other (joint) sessions. The proposed agenda for the ipv6 working group still has quite some room for other topics/presentations. I would very much welcome your input on other interesting topics that you might want to volunteer yourself or somebody else for. There will be a separate session on ipv6 allocation policy where we will discuss the new draft on global ipv6 allocation policies. You have not seen the draft yet but work is progressing really fast now. The draft will be published before the end of the year. An agenda for this will be published later. There will also be a session on RPSL and ipv6 in cooperation with the routing working group. This session will be coordinated by the routing working group chairperson Joachim Schmitz. Thanks, David K. --- Draft agenda (v1) for the IPv6 Working Group Meeting RIPE41, Amsterdam A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of the 6bone (David Kessens) C. IPv6 transition (tentative) (Andrï¿½ Zehl) D. Global IPv6 routing table status G. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) Z. AOB ---

1 0

Draft minutes of the IPv6 wg session at RIPE40
by David Kessens 08 Dec '01

08 Dec '01

Please see below for the first draft version of the minutes of the IPv6 wg session during RIPE40. Please take a look at it and report typos, errors and omissions. The minutes (with possible minor corrections) will be declared final if I receive no comments and/or only minor typographical errors by Fri Dec 21. Thanks, David K. --- Minutes IPv6 working group RIPE 40, Prague, October 2nd, 2001 Chair: David Kessens Number of participants: 83 participants A) Status of 6Bone (David Kessens, presentation available from http://www.kessens.com/presentations/) - Noted growth in IPv6 sites - Better understanding of the system - Growing number of inet numbers - More addresses are being allocated - Addition of two countries - 'co' & 'cu' (presumably Colombia and Cuba) - Number of queries are up - No questions were asked B) Addressing on cable systems (Pascal Julienne) - Reminder: example is a typical site in one city/TV and phone connected to one server - Addressing scheme of cable networks are more complicated when connecting cities i. Routable sites are more complex ii. One WAN for one city, one WAN for another, and so on. iii. As you grow cable networks in a country, you can tie up several cities with different servers, making routing scheme more complex - Why is IPv6 attractive for cable networks? i. Unique address requests from large number of end users ii. IPv6 Anycast address may provide effective web traffic between service points - Host address i. IPv4 vs Mac based addresses 1. Idea is not to renumber but use existing addresses ii. Digital TV - Shows service-based aggregation scheme/aggregate by service i. Two possible ways a. Prefer services over geographical areas b. Geographical areas over service In one case, you can manage all services from one department In the other case, you can manage different cities c. Merged scheme has yet to be examined thoroughly - IPv6 vs IPv4 interaction i. IPv6 or IPv4 or use of a tunnel? - Protocol stack i. Multicast aspect in cable network ii. Most countries use DVB today iii. Modifications need to be made for the future iv. SMPTE 305M is IPv6 compatible but not best for Europe Q: Is there any IPv6 vendor support for cable equipment ?!? A: - End-user's PCs are ahead - Set-top boxes and head-end need IPv6 implementation - Digital TV and telephony support unknown - Where do we go from here? Internet on TV is not going well in Germany but speaker believes it is possible Q: We have a problem with Anycast. A: Anycast works only in the routers and not in the service Anycast needs to be investigated to overcome problems Q: You can connect to the Internet via the private topology/connectivity of IPv6, cable systems, /48 systems? A: it depends how it is managed What I show is not an answer of how to do it but an example Q: Along the lines of Francis ... you can't give an end-user one IP address..., one customer in Paris... A: this is just an example - I am working with Euro and US cable set box manufacturers. In one month I can give you names of several companies who are developing equipment A: can we get the names now? (laughter) C) Global IPv6 Routing Table (Gert Doering, presentation available from http://www.ripe.net/ripe/meetings/archive/ripe-40/) - This will not be scientific but impressions; something to show and discuss - I will give an overview of the topic - What is the routing table? - Protecting addresses i. One big difference to new address: everyone gives transit to others ii. Everybody gets connectivity iii. Underlying topology is different from IPv4 - Some continents have different structures, leading to some interesting observations i. (Shows Saturdays' numbers) ii. 6BONE iii. Most important for the future is a /35 iv. Shows distribution graph of total number of prefixes since Saturday v. Shows graph separating from 6BONE and registry base vi. Shows new slide of RIRs, AS, and AS paths vii. Overall there are 171 addresses participating in the table? viii.Average number of Hops is so similar via IPv6 vs IPv4 ix. Observations of 'crap' in the table x. Problems of address length and of too many hops xi. Find out what router is causing them and fix xii. Lazy aggregation - Cable & Wireless example xiii.Need to be more careful of what is put into the IPv6 table otherwise it will look like IPv4 table, full of 'crap' xiv. Invalid AS numbers (shows example of Mexican ISP) Comment: I saw AS numbers being stolen (gasps/laughs) - I want to make IPv6 work, so if people use 'crap', I will use that For now, I just observe weird things and call them to make them stop - Conclusions: it works, people are hooking up to IPv6, it is still experimental, people are cooperative, interest is growing, even with the illegalities (stealing, etc.) Comment: on filtering - we can discuss this at next meeting - We need to be careful of which packets are used for certain circumstances - Shows slide of references Comment: We have 250 routes; it would be interesting to have a registry as we did before. - This is something to be discussed later Q: You mentioned what could we do to improve? Anything we can do here (at RIPE?) A: We can look at the table and if we see irregularities; just ask them for the reason; many may not respond; but if everyone just talks to their neighbor.ask if it is done on purpose.. Q: I am tempted to place this on the agenda topic next time. Q: I want to ask people what addressing scheme they use for point-to-point links A: I use 127's. I have never seen any problems using them. D) Discussion on RPSL and IPv6 routing policies (Florent Parent, presentation available from http://www.ripe.net/ripe/meetings/archive/ripe-40/) Florent discussed whether the implications on RPSL regarding RPSL. He discussed the various options of adding attributes and classes. The decision was made to form a maillist to discuss the RPSLng: <rpslng(a)ripe.net> E) Pan-European IPv6 IX Backbone (Jordi Palet, presentation available from http://www.ripe.net/ripe/meetings/archive/ripe-40/) - Remarks on receiving funding for IX backbone - Began project in April 1983 - Project still under negotiation i. Hopefully, we'll start on December 1st - Correct pronunciation: 'Euro6IX' as in 'EuroSix' - Build a native IP structure i. Want it to be 'open' - Will receive funding from the EU - "Chicken and Egg" problem overcome - Gaining real IPv6 experience in the real world i. Simulates real commercial networks - Euro6IX Goals and Objectives i. Consortium numbers 1. Main Telco's represented by their research arms 2. Universities 3. Sponsors are international ("and it's just starting") ii. Network hierarchy iii.Network map iv. Infrastructure set-up v. Work package summary vi. Research activities vii.Users/User group involvement viii.Access Usage policy 1. For EU funding, we must stay clear of conflicts F) IPv6 in European Region Input from the audience requested: IST/6NET IPv6 testbed (Bernard Tuy, presentation available from http://www.ripe.net/ripe/meetings/archive/ripe-40/) Q: What is the difference between Euro6IX and IST? A: Membership is different Q: But the goals seem to be the same. A: Yes, most are the same. Both projects will incorporate a lot and be common but will never be equal. Money has been put into IPv6 development and that's important.

1 0

WG: I-D ACTION:draft-ietf-ipngwg-rfc2013-update-01.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:14 An: IETF-Announce: Cc: ipng(a)sunroof.eng.sun.com Betreff: I-D ACTION:draft-ietf-ipngwg-rfc2013-update-01.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 : Management Information Base for the User Datagram Protocol (UDP) Author(s) : B. Fenner et al. Filename : draft-ietf-ipngwg-rfc2013-update-01.txt Pages : 22 Date : 21-Nov-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) [4] in an IP version independent manner A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2013-update-01.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-rfc2013-update-01.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-rfc2013-update-01.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-rfc2013-update-01.txt

1 0

WG: I-D ACTION:draft-ietf-ipngwg-rfc2012-update-01.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:14 An: IETF-Announce: Cc: ipng(a)sunroof.eng.sun.com Betreff: I-D ACTION:draft-ietf-ipngwg-rfc2012-update-01.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 : Management Information Base for the Transmission Control Protocol (TCP) Author(s) : B. Fenner et al. Filename : draft-ietf-ipngwg-rfc2012-update-01.txt Pages : 26 Date : 21-Nov-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Transmission Control Protocol (TCP) [5] in an IP version independent manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2012-update-01.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-rfc2012-update-01.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-rfc2012-update-01.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-rfc2012-update-01.txt

1 0

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