- ipv6-wg - mailman.ripe.net

Fw: Consensus on "IPv6 Multihoming with Route Aggregation"
by Thomas Trede 30 Jul '00

30 Jul '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <ipng(a)sunroof.eng.sun.com> Cc: <hinden(a)iprg.nokia.com>; <deering(a)cisco.com> Sent: Thursday, July 27, 2000 11:35 PM Subject: Consensus on "IPv6 Multihoming with Route Aggregation" > At the September 1999 Tokyo IPng meeting a consensus was developed to move > "IPv6 Multihoming with Route Aggregation" forward along with other > multihoming approaches (e.g., "IPv6 multihoming support at site exit > routers", source and destination address selection, etc.). This was > discussed again at the November 1999 Washington, DC IPng meeting. > > The draft was revised based on comments (including renaming it to it's > current title) and a two week working group last call was started on 23 Jun > 2000. There was an active discussion on the IPng mailing list. > > The IPng chairs believe that there is still a consensus to move the > document forward to Informational. There were a few active dissenters, but > the chairs believe that this draft is a useful part of the IPv6 multihoming > framework and that there is still a consensus to request that the IESG > published it as an Informational RFC. > > Bob Hinden / Steve Deering > IPng Chairs > > > -------------------------------------------------------------------- > 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

Fw: Request to Advance "IPv6 Multihoming with Route Aggregation"
by Thomas Trede 30 Jul '00

30 Jul '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <narten(a)raleigh.ibm.com>; <Erik.Nordmark(a)eng.sun.com> Cc: <scoya(a)ietf.org>; <deering(a)cisco.com>; <ipng(a)sunroof.eng.sun.com>; <hinden(a)iprg.nokia.com> Sent: Thursday, July 27, 2000 11:45 PM Subject: Request to Advance "IPv6 Multihoming with Route Aggregation" > The chairs of the IP Next Generation working group, on behalf of the > working group, request that the following document be published as an > Informational RFC: > > Title : IPv6 Multihoming with Route Aggregation > Author(s) : J. Yu > Filename : draft-ietf-ipngwg-ipv6multihome-with-aggr-00.txt > Pages : 7 > Date : 24-Nov-99 > > A consensus was developed at the Tokyo (9/1999) and Washington, DC > (11/1999) IPng meetings to move this document forward. A working group > last call for this document was completed on July 7, 2000. There was an > active discussion during the last call. The w.g. chairs conclude from the > discussion that there is a consensus in the w.g. to move this document > forward as an Informational RFC. > > This document is part of the IPv6 multihoming framework. The working group > will also be advancing other documents dealing with other aspects of IPv6 > multihoming. > > Bob Hinden / Steve Deering > IPng Working Group Chairs > > > > > -------------------------------------------------------------------- > 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

Fw: Request to Advance "IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol"
by Thomas Trede 27 Jul '00

27 Jul '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <narten(a)raleigh.ibm.com>; <Erik.Nordmark(a)eng.sun.com> Cc: <scoya(a)ietf.org>; <deering(a)cisco.com>; <ipng(a)sunroof.eng.sun.com> Sent: Wednesday, July 26, 2000 11:13 PM Subject: Request to Advance "IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol" > Erik, Thomas, > > The chairs of the IP Next Generation working group, on behalf of the > working group, request that the following document be published as a > Proposed Standard: > > Title : IP Version 6 Management Information Base for the > Multicast Listener Discovery Protocol > Author(s) : B. Haberman, R. Worzella > Filename : draft-ietf-ipngwg-mld-mib-04.txt > Pages : 14 > Date : 25-Jul-00 > > A working group last call for this document was completed on July 3, > 2000. The above draft resolves issues raised during the last call. > > Bob Hinden / Steve Deering > IPng Working Group Co-Chairs > > -------------------------------------------------------------------- > 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

Fw: Request to Advance "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification"
by Thomas Trede 27 Jul '00

27 Jul '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <narten(a)raleigh.ibm.com>; <Erik.Nordmark(a)eng.sun.com> Cc: <scoya(a)ietf.org>; <deering(a)cisco.com>; <ipng(a)sunroof.eng.sun.com> Sent: Thursday, July 27, 2000 12:25 AM Subject: Request to Advance "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" > Erik, Thomas, > > The chairs of the IP Next Generation working group, on behalf of the > working group, request that the following document be published as an > Proposed Standard: > > Title : Extensions to IPv6 Neighbor Discovery for Inverse > Discovery Specification > Author(s) : A. Conta > Filename : draft-ietf-ion-ipv6-ind-04.txt > Pages : 21 > Date : 13-Jul-00 > > A working group last call for this document was completed on July 6, > 2000. The -04 version of the draft resolves issues raised during the last > call. > > This document was originally a ION w.g. document and was transferred to the > IPng w.g. when the ION w.g. concluded. > > Bob Hinden / Steve Deering > IPng Working Group Co-Chairs > > -------------------------------------------------------------------- > 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

Fw: I-D ACTION:draft-ietf-ipngwg-mld-mib-04.txt
by Thomas Trede 26 Jul '00

26 Jul '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Wednesday, July 26, 2000 12:50 PM Subject: I-D ACTION:draft-ietf-ipngwg-mld-mib-04.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 : IP Version 6 Management Information Base for the > Multicast Listener Discovery Protocol > Author(s) : B. Haberman, R. Worzella > Filename : draft-ietf-ipngwg-mld-mib-04.txt > Pages : 14 > Date : 25-Jul-00 > > This document defines an experimental portion of the Management > Information Base (MIB) for use with network management protocols in > Internet Protocol Version 6 internets. Specifically, this document > is the MIB module which defines managed objects for implementations > of the Multicast Listener Discovery Protocol [MLD]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-mld-mib-04.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-mld-mib-04.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-mld-mib-04.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. >

1 0

Fw: I-D ACTION:draft-ietf-ipngwg-default-addr-select-01.txt
by Thomas Trede 21 Jul '00

21 Jul '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Friday, July 21, 2000 3:07 PM Subject: I-D ACTION:draft-ietf-ipngwg-default-addr-select-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 : Default Address Selection for IPv6 > Author(s) : R. Draves > Filename : draft-ietf-ipngwg-default-addr-select-01.txt > Pages : 12 > Date : 20-Jul-00 > > 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-01 .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-default-addr-select-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-default-addr-select-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. >

1 0

Fw: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-06.txt
by Thomas Trede 21 Jul '00

21 Jul '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Friday, July 21, 2000 3:07 PM Subject: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-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 : IPv6 Node Information Queries > Author(s) : M. Crawford > Filename : draft-ietf-ipngwg-icmp-name-lookups-06.txt > Pages : 14 > Date : 20-Jul-00 > > This document describes an experimental protocol for asking an IPv6 > node to supply certain network information, such as its fully- > qualified domain name. IPv6 implementation experience has shown > that direct queries for FQDN are useful, and a direct query > mechanism for other information has been requested. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-06.t xt > > 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-icmp-name-lookups-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-icmp-name-lookups-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. >

1 0

Fw: Document Action: Initial IPv6 Sub-TLA ID Assignments to Informational
by Thomas Trede 21 Jul '00

21 Jul '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "The IESG" <iesg-secretary(a)ietf.org> To: <IETF-Announce: ;> Cc: "RFC Editor" <rfc-editor(a)isi.edu>; "IANA" <iana(a)iana.org>; "Internet Architecture Board" <iab(a)isi.edu>; <ipng(a)sunroof.eng.sun.com> Sent: Friday, July 21, 2000 3:26 PM Subject: Document Action: Initial IPv6 Sub-TLA ID Assignments to Informational > > > The IESG has approved the Internet-Draft 'Initial IPv6 Sub-TLA ID > Assignments' <draft-ietf-ipngwg-iana-tla-03.txt> as an Informational > RFC. This document is the product of the IPNG Working Group. The IESG > contact persons are Erik Nordmark and Thomas Narten. > > Note to RFC Editor: > > 1) Remove the last paragraph in Section 1, the one defining > MUST/MAY/SHOULD terminology. In addition, remove the reference to > RFC 2119 in the references section. > > 2) Insert the following paragraph as the first paragraph in the > Introduction section: > > This document was originally developed to provide advice to IANA in > the fall of 1998 and is being published at this time for the > historical record. The IAB subsequently requested that the IANA > delegate these assignments to the Address Registries. The IANA did > this and the Address Registries are now using them to assign IPv6 > addresses. > > -------------------------------------------------------------------- > 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

Fw: RFC 2874 on IPv6 DNS
by Thomas Trede 20 Jul '00

20 Jul '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "RFC Editor" <rfc-ed(a)ISI.EDU> To: <IETF-Announce: ;> Cc: <rfc-ed(a)ISI.EDU>; <ipng(a)sunroof.eng.sun.com> Sent: Thursday, July 20, 2000 12:55 AM Subject: RFC 2874 on IPv6 DNS > > A new Request for Comments is now available in online RFC libraries. > > > RFC 2874 > > Title: DNS Extensions to Support IPv6 Address Aggregation > and Renumbering > Author(s): M. Crawford, C. Huitema, S. Thomson > Status: Standards Track > Date: July 2000 > Mailbox: crawdad(a)fnal.gov, huitema(a)research.telcordia.com, > set(a)research.telcordia.com > Pages: 20 > Characters: 44204 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-ipngwg-dns-lookups-08.txt > > URL: ftp://ftp.isi.edu/in-notes/rfc2874.txt > > > This document defines changes to the Domain Name System to support > renumberable and aggregatable IPv6 addressing. The changes include > a new resource record type to store an IPv6 address in a manner > which expedites network renumbering and updated definitions of > existing query types that return Internet addresses as part of > additional section processing. > > For lookups keyed on IPv6 addresses (often called reverse lookups), > this document defines a new zone structure which allows a zone to be > used without modification for parallel copies of an address space > (as for a multihomed provider or site) and across network > renumbering events. > > This document is a 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. >

1 0

minutes of the IPv6 working RIPE 36
by David Kessens 20 Jul '00

20 Jul '00

Hi, Please see below for the final version of the minutes of the ipv6 working group session at RIPE 36. The following problems were discovered and corrected: a few typos, the number of attendees was added and the attribution of the people who setup the terminal room demo was corrected (The demo was setup by: Laurent Toutain, Francis Dupont, and Octavio Medina (all from ENST Bretagne)). I would like to thank Jeroen Bet from the RIPE NCC for taking the minutes. David K. --- minutes of the IPv6 working group Budapest 20000523 RIPE Meeting: 36 Working Group: IPv6 Budapest 20000517 IPv6 Working Group Chair: David Kessens Scribe: Jeroen Bet # of attendees: 74 A. Administrative stuff - Appointment of scribe - Agenda bashing B. Status of 6bone (David Kessens) C. A presentation from the Ipv6 EVENT in Birmingham (UK) 20000510 by (Stuart Prevost) D. News from the IPv6 forum and meeting in Telluride (Juergen Rauschenbach) E. Status of IPv6 Allocation Guideline draft (Joao) F. European developments/initiatives regarding IPv6 (input from the audience) G. Reports on on-going projects, success & failures stories on IPv6 H. Future plans for the working group I. Input for the 2001 activisty plan of the RIPE NCC Z. AOB Action points from RIPE 35: NONE New action points from RIPE 36: on the chair to summarize the discussion and to collect more advise and post it to the IPv6 mailing list. A. Administrative stuff - Jeroen Bet was appointed scribe - Agenda was approved with one addition: A presentation from the Ipv6 EVENT in Birmingham (UK) 20000510 by Stuart Prevost under C. B. Status of 6bone http://www.kessens.com/~david/presentations/ David Kessens: The number of sites, allocations have all increased since 20000222. There are now 46 countries represented in 6BONE (was 42). The number of Queries have been once again decreased due to the database downloads by members. C. A presentation from the Ipv6 EVENT in Birmingham (UK) 20000510 http://www.ipv6forum.com/navbar/events/birmingham00/presentations/ Stuart Prevost The IPv6 FORUM event in Birmingham, UK was organised by BT and sponsored by Cisco. It was an overall promotion day for IPv6. The key speakers were Chris Earnshaw (BT) who had a presentation called "The new wave ISP" where he pleaded that ISP's should upgrade now, because the longer the upgrade to IPv6 is postponed, the costlier it will be. Another presentation was by Peter Kirstein (University College London) on the "new Internet" and Mario Campolargo (Head of research Networks - -European Commission) had a presentation on European Strategic Initiatives. The key point here was that the demand for IPv6 has to be there, you can't just say from now on we will use IPv6. Several projects were supported and initiated by the European Commission to promote IPv6. There were several more presentations (Nokia, Ericsson, Telia and others)in Birmingham. More information about the event including the presentations is located at: D. News from the IPv6 forum and meeting in Telluride http://www.ipv6forum.com/ http://www.ipv6forum.com/navbar/events/telluride00/presentations/ (Juergen Rauschenbach) The IPv6 forum has 5 new members, 2 from the US, 2 from the Asia Pacific region and 1 from Europe. A list of members is located at: A 2 day conference was held in Telluride (US) which included a one day tutorial by Florent Parent and Regis Desmeules, Viagenie. Judy Estrin, CTO and Senior Vice President, Cisco Systems gave a presentation which called for *integration* of IPv6 not a *transition*. Furthermore various vendors announced upgrades and new releases of their products which are now compatible with IPv6. will give you an overview of all the presentations during the summit. There are also MP3 files of the key speeches as well as a PDF file of the IPv6 tutorial. The next big IPv6 thing is in London in June, and there is a summit in Japan coming up at the end of the year. Also from November 29th until December 1st there is a 3 day conference on IPv6 in Madrid. E. Status of IPv6 Allocation Guideline draft (Joao) A discussion started following the discussions at the IETF meeting held in Adelaide, especially on whether to use /48s, /56s, or /64s for end-users. One of the obvious problems is the definition of an end-user itself. The issue was raised in the ARIN meeting in Calgary (20000403). The question popped up which direction to take? Should we conserve address-space as much as possible or should we give end-users a little more addresses to make it easier from an administrative point of view. Bill Manning pointed out that these were early days in the IPv6 world, so should we decide on this issue now? Gert Doering brought up the issue of administrative ease. If we issue a /56, it will be easier for ISP's. A lot of people felt that being a bit more flexible is ok but we shouldn't be too flexible. Stephen Burley said that giving an end-user more than what they needed could create complications later on. Some people felt that a /64 was too small but a /48 was too big for an end-user so a /56 would be a good compromise. Wilfried Woeber: we should be cautious about re-shuffling policies. IPv6 is overall more interesting for large networks. Having 8 bits for subnets is not enough. Giving a /64 to any end user that is not big enough to qualify for a /48 could cause problems. Someone pointed out why there was a need to use fixed boundaries when we all use CIDR. David Kessens concluded from the arguments that the attendees brought up that a /64 is not enough as a default assignment. If a LIR issues a /56 or /48 for a default would this be reasonable? Again there was no consensus over this. As the issue of /64 vs. /56 was brought up in the IETF meeting in Adelaide, people started wondering why the IETF is so terrified of giving all end-users 'only' a /64? It seems that the IETF doesn't want NAT to be used with IPv6. Also subnetting and bridging in a /64 is highly undesirable. Giving them a /56 will give end-users the incentive not to do this. Paul Wilson: There is no engineering reason to select a /48 opposed to a /56. a /48 is big enough for any site. However a /48 is way too big for a dial up account -> give them a /64. LIR's should give a /64 for mobile phones, enough for one subnet. There would be no reason for assigning more than a /56 for home use. Assign any length that a user needs in the foreseeable future. We assume a home site will have one provider but every household will have many side addresses. This so far seems not to be anticipated. IPv6 will have to last forever, so do not throw away address-space. Is a floating boundary preferred? Some attendees said yes. It will initiate the end-users thinking process of how much they actually need. It is the ISP's decision of how much address-space to give to an end-user. In fact this would be the same principle that we use for IPv4. There was no consensus over a floating boundary. A question came up what the community will do with the bits we save in the SLA space. What happens if an ISP runs out of space? The question was left unanswered. - -> ACTION on the chair to summarize the discussion and to collect more advise and post it to the IPv6 mailing list. David Kessens concluded that we need to find a balance between conservation and administrative flexibility. F. European developments/initiatives regarding IPv6 topic was skipped because of lack of time G. Reports on on-going projects, success & failures stories on IPv6 topic was skipped because of lack of time H. Future plans for the working group topic was skipped because of lack of time I. Input for the 2001 activisty plan of the RIPE NCC topic was skipped because of lack of time Z. AOB Bernard Tuy and Laurent Toutain invited all the attendees to the IPv6 platform demonstration which was set up by Laurent Toutain, Francis Dupont, and Octavio Medina (all from ENST Bretagne). Q: Should we set up a global mailing list for IPv6 issues? There are several now in various regions and it might be an idea to coordinate this. Especially for the discussion about the size of the assignments. 17.00 The meeting was closed

1 0