- ipv6-wg - mailman.ripe.net

draft minutes of RIPE35
by David Kessens 22 Mar '00

22 Mar '00

Hi, Please see below for the minutes of RIPE 35. I would like to thank Monica Cortes for doing the hard work of taking the minutes and turning them in to me quickly after the meeting. Please let me know if you find any typos, errors or omissions. The minutes will become final by April 7, 2000 if no problems are found besides typographical errors. David K. --- ------------------------------------------------------------------------- RIPE 35 Amsterdam, 23rd January 2000 IPv6 Working Group Chair: David Kessens Scribe: Monica Cortes A. Administrative stuff - Appointment of scribe - Agenda bashing B. Comments on the Provisional Assignment and Allocation of IPv6 Addresses Policy Document (IPv6 WG - LIR WG) (Mirjam Kuehne) - Why is the dial-up link treated differently - should such users get a /48 or a /64? - Public or private addresses for point-to-point links? - What constitutes 80% utilisation? C. Status of 6bone (David Kessens) D. Issues with filtering of 'IPv6 in IPv4' packets (Thomas Trede) E. IPv6 Meeting in Berlin (Thomas Trede) && IPv6 Forum (Juergen Rauschenbach) F. Quick summary of EOF morning session (Wilfried Woeber) G. European developments/initiatives regarding IPv6 (input from audience) H. Reports on on-going projects, success & failure stories on IPv6 (input from audience) I. Input from other working groups Z. AOB Action points from RIPE 34: NONE Action points from RIPE 35: NONE -------------------------------------------------------------------------- -- A -- Administrative stuff Scribe was appointed, the agenda was approved without changes --B -- IPv6 Policy Document Review (ripe-196) (Mirjam Kuehne) Mirjam presented the open issues and possible points of disagreements of the Allocation of IPv6 addresses document currently in use (ripe-196). It was created in April of last year, it was reviewed by all RIR's regions and the IETF. More discussions on all RIR regions will take place in the near future and the input is welcomed: RIPE meeting this week, next week is the APNIC/APRICOT meeting, ARIN meeting is the first week of April, RIRs will have a retreat the second week of April, where this document will be discussed. New draft document will be available before RIPE 36. 11 allocations have been made so far. Open Issues: * section 4.2.3.2 on multi-homing, to be written, currently missing Mirjam: There is little experience in multimhoming and is still an open issue being discussed at the IETF and EOF. Should the multi-homed have two NLAs assigned each from one provider? Person1: It is better to assign only one NLA as otherwise he would need to AS numbers and which should he use? Person2: What is multi homing? one node with several ip addresses or better one address accessed via multiple paths? David Kessens: Multi-homing is a non solved problem but needs an allocation policy. Wilfried Woeber: The definition of multi-homing is not clear yet, we should use multi-homing with the current understanding of this term. PI addresses are not valid for IPv6, we don't want to allocate a TLA for all multi-homed sites. Person1: Then multi-homing can only be done by big organisations Person3: What is wrong with multiple AS numbers? Person4: BGP does work, but will stop working if the number of ASN keep growing as now. There will be a shortage of ASN and huge tables. BGP does not scale and won't work. David Kessens: Aggregation is the only solution for this Person1: Ok, then let's renumber when a solution is in place David Kessens: IPv6 design tells you how to do things. The allocation document should not have things different than what the standard defines. It is not politically correct Mirjam: We should have some text on the document Person5: Lets add to the text that it is provisional as there are no standards yet * section 4.2.8 on allocations to NLA registries * section 4.3.1 on assignments to end users Mirjam: There is no sufficient experience available still, there are no policies and procedures available, input from the community is appreciated. Bernard Tuy: A proposal would be that they come back when your TLA is allocated an 80% on one level of hierarchy. Person: Why not indicate that this is a life document and that it can be reviewed in the future? Daniel Karrenberg: Lets put a date for review. * definition of "transit-provider" mentioned in the document. Mirjam: The IETF would not come to a definition of this either and they recommended to remove it altogether from the text. This is our recommendation as well. WG agrees. * definition of TLA/NLA/SLA registry Mirjam: Is a TLA registry the one allocation or assigning TLAs or the one receiving the allocation? The proposed idea is that a TLA registry is the one that allocating or assigning TLA addresses. The same goes for NLA and SLA registries. WG agrees. * section 3.2 on Point-to-Point links Mirjam: should they have public or private addresses? The IETF chair suggests them to be public addresses. Should we remove the paragraph altogether? David Kessens: I agree with the chair, aggregation is the important thing not conservation. This is not the time to save address space. Person: (Nods) it is valuable to drop it and have global addresses for debugging purposes WG agrees. * section 4.3.1 on Dial-up Assignments Mirjam: There is controversy about what subnet size should be assigned to a Dial-up customer: a /48 or a /64? There is no enough experience on this; only on NLA allocations or assignments reassigned from the 11 sTLAs. IETF suggests to give a /48. Person1: What if we just put a magic number, nobody really knows what makes sense. We could indicate that this will be reviewed. Wilfried Woeber: I agree with the IETF on the Point-to-Point links, but why a /48 instead of a /64 for my dial-up host at home? Mirjam: Should we create a group that investigates this issue? Wilfried Woeber: Technical aspects should be investigated and then come up with a recommendation or a BCP. Person2: Every user of mobile phones will get a /48? It is difficult to discuss where to put the boundary for a /48 or /64. We need more experience? David Kessens: One possibility would be to have a /64 for one single network and a /48 for more than that. Mirjam: We will have more discussions with the other RIRs and come back with a proposal. * section 4.2.5 on 80% Utilisation Mirjam: There is a question on what is meant by 80% Utilisation, is this on only one level of hierarchy or all the address space allocated? Do all the allocations and assignments need to be registered? Person: 80% is a xxx million customers. Will that ever be full? Daniel Karrenberg: This was a safeguard for people who wanted to be assured that they could grow and have more addresses in a future point in time. Person1: How to use the NLA field? One can imagine all types of possibilities from the bad two extremes: - NLA1 has 1 bit which means 2 ISPs and NLA2 field 8bits or 256 end sites or - NLA1 has 8bits or 256 possible ISPs and NLA2 field 1 bit so 2 end sites each David Kessens: IETF WG chairs say that a /29 is already a slow start, a /35 is not much. There is a fear that conservation is the main argument and not aggregation Mirjam: Aggregation is the key of the document, we allocate a /35 but we reserve the rest of the /29. We will give more space depending on the usage rate. If the usage rate is high the next allocation will be the full /29. If it is slow only a few more bits will be given. Wilfried Woeber: We need more real life experience before changing the document David Kessens: What expiry date should the document have? After WG input agreed upon: 12 months Bernard Tuy: I would like to say to the RIPE NCC: keep it going! It is very useful to have this discussions also months after the first document was drafted. COFFEE BREAK -- C -- Status of the 6bone (David Kessens) Presentation can be found at: http://www.kessens.com/~david/presentations/ In the last 4 months the 6bone registry as seen a 15% growth. The number of countries that have joined the 6bone is stable now. The number of queries have decreased about 20% to 2400 queries a day. This is because a heavy user of the database is now running a mirror of his own. The number of updates is stable as well, about 8 update a day. -- D -- Issues with filtering of 'IPv6 in IPv4' packets (Thomas Trede) Presentation can be found at: http://www.tu-darmstadt.de/hrz/staff/data/trede/RIPE35-trede-ipv6conf.ppt Thomas asked the audience if anyone had experienced any type of filtering of IPv6 traffic by filtering IPv6 in IPv4 packets. This had been seen by some people although it was not confirmed. Wilfried Woeber: Is it general tunnel filtering or targeted filtering? Thomas Trede: Only one site experienced this, and it is not clear what type of filtering it is. It is good to see that no-one else in the audience had experience something similar. -- E1 -- IPv6 Meeting in Berlin (Thomas Trede) This is the second IPv6 forum meeting and was held in Berlin. There were many talks so only the highlights of the talks will be presented here. More about this meeting can be found in http://www.berkom.de/ipv6 Presentations: - NTT plans a world wide IPv6 native network. NTT won't charge for access to their IPv6 network from USA or EU. - NATO announced in 1999 the principal decision to go for IPv6 The German Navy have an IPv6 Application with QoS for the Navy. - Deutsche Telekom outlined the DTAG, ecomerce and end-to-end security - CSELT had a demo of tunnel-broker. In less than 1 minute one could have ipv6 connectivity - IPv6 forum Chair talked about the Forum Mission and membership (70 members) - Vendors & ISPs are moving forward: - Sun, Compaq (Digital) will have IPv6 in their new OS version - Routers: Telebit has IPv6, Cisco say: 'by the 2nd half of 2000', their IOS has still bugs in their current version - Microsoft: Windows 2000 won't have IPv6 - Kame project has been prolonged until 3/2002 - 3Com had a presentation about 6over4. Support fro IPv6 in the USA is increasing Conclusions: - The implementations are stable and ready, in the router market Cisco is the mayor obstacle. - More engagement of ISPs is needed. More connectivity tests need to be performed, tests on Exchange Points, and customer connectivity. - Are we ready? There is the chicken and egg problem: Hardware or software, everyone points to the other-one. -- E2 -- IPv6 Forum (Juergen Rauschenbach) Presentation can be found at: http://www.kessens.com/~david/presentations/ The Forum's Mission is to promote IPv6 by improving the market and user awareness of IPv6, creating a quality and secure Internet. It promotes new IPv6-based applications and solutions, promotes the knowledge and experience sharing among members, resolve issues that create barriers to IPv6 deployment. There are 78 members per 17th February: 29 in North America, 36 in Europe, 13 in Asia/Pacific. There are 12 research organisations and the biggest group are network suppliers, though bit telco's and ISPs are also present. The IPv6 Forum consists of a Board of 8 members, a Promotion Group (15 Marketers) and a Deployment Group (34 Experts). In this last group is the IPv6 Technical Directorate that is responsible for the technical part of the Forum, gives direction and advice to the Forum and the industry and makes the link between IETF and the industry. The Promotion Group has IPv6 education and awareness programs, organises global IPv6 Summit/Conferences, has a Strategic Alliance Program and Strategic Alliances with the UMTS Forum, the GSM Association, Stardust.com, GIPF (France), ETSI (EU) and 3GPP. IPv6 Summit Program: - Oct 1999 Paris - Dec 1999 Berlin NEW: - 14-15th March 2000 in Colorado, US Summit - 10th May 2000 in Birmingham, UK IPv6 Event - Oct 2000 in Tokyo, IPv6 Summit - 29th Nov - 1st Dec 2000 in Madrid (Spain), IPv6 Summit IPv6 Forum participates and cooperates in other events: - 14-16th March 2000 in Paris, on Mobile.ISP - 15-17th March 2000 in UK, on IP QoS - 28-29 Oct 1999 in Paris, on IPSec 6INIT (IPv6 INternet IniTiative) is one of the projects of IPv6 Forum. Some links: - IPv6 Forum: www.ipv6forum.com - Berlin Summit: www.berkom.de/ipv6 - US Summit: www.stardust.com/ipv6summit - sTLA allocations: www.dfn.de/service/ipv6/ipv6aggis.html - 6INIT: www.6init.org -- F -- Quick Summary of EOF morning session (Wilfried Woeber) There were two presentations one from Stuart and the other from Woeber. Both presentations were largely in agreement about the results and future way to go. There is still work needed on IPv6 routing and DNS infrastructure of IPv6 transport. Person: We found two mayor problems on our setup. One is finding the bit boundaries and having new procedures, and the second is that we found problems in our accounting and billing infrastructure. David Kessens: I will try to organise an IPv6 tutorial, something more hands-on -- G -- European developments / initiatives regarding IPv6 (input from audience) Bernard Tuy: We want to deploy an IPv6 native backbone in our topology. There will be more info in slides in Budapest. -- H -- Reports on ongoing projects, success & failure stories (input from audience) no input -- I -- Input from other working groups David Kessens: EIX working group was talking about allocations of TLA to exchange points and could not take any resolution on this, so this point has come back to the IPv6 WG. Mirjam Kuehne: The IX points don't think it is a good idea to act as an NLA registry for their members. The RFC has this possibility as a concept, but the EIX did not see it as feasible at this point in time. Christian Panigl: The IX would have to give transit to the transit points of members. This is a contradiction of the neutrality of an IX point. Mirjam Kuehne: The IETF worked on the possibility of the existence of a different type of IX point. Bernard Tuy: Where should these policy discussions take place: LIR WG, IPv6 WG the EIX WG? How can we have better interactions? David Kessens: For this reason we hold a joint WG session with LIR WG in the first half. Wilfried Woeber: In order to tackle the problem, we should set up an editorial commity that puts comments and suggestions together and forward the document to the mailing list or move the IP address issues to the LIR mailing list to focus the discussions. David Kessens: It is an LIR issue, but IPv6 is still experimental and should be kept in this WG. Bernard Tuy: Let's keep it like today in shared sessions. Mirjam Kuehne: After the meetings with the other RIRs, we will submit the document to the IPv6 WG and LIR WG. In the IPv6 WG the people are more involved in these issues. -- Z -- AOB none. Session closed

1 0

BT & Microsoft Press Release
by stuart.prevost＠bt.com 21 Mar '00

21 Mar '00

FYI BT & Microsoft Research (Cambridge) published a press release yesterday regarding tunnel broker access to BT IPv6 trial network http://www.bt.com/World/news/newsroom/index.htm For further information on this collaboration and the IPv6 trials on LEANet please contact me. Regards, Stuart Prevost --------------------------------------------------- IP Specialist, Futures Testbed Tel: +44 1473 646891 Fax: +44 1473 643906 Mobile: +44 7801 977290 Email: stuart.prevost(a)bt.com Addr: B29/136 - Adastral Park, Martlesham Heath, Ipswich. Suffolk. IP5 3RE

1 0

[tjc@ecs.soton.ac.uk: MSR Win2000 kit is now available]
by David Kessens 20 Mar '00

20 Mar '00

----- Forwarded message from Tim Chown <tjc(a)ecs.soton.ac.uk> ----- Date: Mon, 20 Mar 2000 17:16:45 +0000 (GMT) From: Tim Chown <tjc(a)ecs.soton.ac.uk> To: members(a)ipv6forum.com Subject: MSR Win2000 kit is now available Precedence: bulk Delivered by MS Research as promised: http://msdn.microsoft.com/downloads/sdks/platform/tpipv6.asp Cheers, Tim ----- End forwarded message ----- David K. ---

1 0

Fw: Congratulations to KAME Project
by Thomas Trede 20 Mar '00

20 Mar '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <itojun(a)iijlab.net> To: <george+ipv6(a)m5p.com> Cc: <users(a)ipv6.org> Sent: Sunday, March 19, 2000 12:57 AM Subject: Re: Congratulations to KAME Project > > >Congratulations to the KAME project! > > > >First, belated congratulations on your continued funding. This is excellent > >news for the entire Internet community, and for IPv6 in particular. > > > >Second, I upgraded my FreeBSD system from 3.2+KAME-stable-Approx. September > >to 3.4+KAME-stable-February. It's been up continuously for seven days now. > >Congratulations on a fine release! I heard that the KAME stack will be > >standard in FreeBSD 4.0, and that's good news too. > > THank you very much for your message, FreeBSD 4.0 started shipping > last week (Mar 13), with kernel/userland IPv6 support **enabled by > default**. > > itojun > > --------------------------------------------------------------------- > The IPv6 Users Mailing List > Unsubscribe by sending "unsubscribe users" to majordomo(a)ipv6.org >

1 0

Fw: HP-UX IPv6 Developer's Kit version 1.1
by Thomas Trede 20 Mar '00

20 Mar '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "David Wang" <dsw(a)cup.hp.com> To: <ipng(a)sunroof.eng.sun.com> Sent: Saturday, March 18, 2000 1:35 AM Subject: HP-UX IPv6 Developer's Kit version 1.1 > Hewlett-Packard Company announces the release of the HP-UX IPv6 > Developer's Kit version 1.1 > > The HP-UX IPv6 Developer's Kit version 1.1 supports the IETF IPv6 > standards that will provide IPv6 functionality on HP-UX 11.00. IPv6 is a > new version of the Internet Protocol that provides a larger address space, > simple network configuration, and better security. The IPv6 Developer's > Kit enables the Internet community to evaluate and experiment with the > IPv6 protocol on HP-UX 11.0. > > More details are available at: > > http://www.software.hp.com > > Please search for "IPv6". > > The HP-UX IPv6 development team > > -------------------------------------------------------------------- > 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: US IPv6 Forum Summit presentations online
by Thomas Trede 17 Mar '00

17 Mar '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Tim Chown" <tjc(a)ecs.soton.ac.uk> To: <ipng(a)sunroof.eng.sun.com>; <ngtrans(a)sunroof.eng.sun.com> Sent: Thursday, March 16, 2000 9:05 PM Subject: US IPv6 Forum Summit presentations online > > Hi, > > The US IPv6 Summit presentations from Telluride are now online at > > http://www.ipv6forum.com > > in HTML, Powerpoint and zipped PDF formats. > > The link is from the top of the front page. > > Cheers, > Tim > > > > -------------------------------------------------------------------- > 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-router-renum-10.txt
by Thomas Trede 17 Mar '00

17 Mar '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, March 17, 2000 2:21 PM Subject: I-D ACTION:draft-ietf-ipngwg-router-renum-10.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 : Router Renumbering for IPv6 > Author(s) : M. Crawford > Filename : draft-ietf-ipngwg-router-renum-10.txt > Pages : 31 > Date : 16-Mar-00 > > IPv6 Neighbor Discovery and Address Autoconfiguration conveniently > make initial assignments of address prefixes to hosts. Aside from > the problem of connection survival across a renumbering event, these > two mechanisms also simplify the reconfiguration of hosts when the > set of valid prefixes changes. > This document defines a mechanism called Router Renumbering ('RR') > which allows address prefixes on routers to be configured and > reconfigured almost as easily as the combination of Neighbor > Discovery and Address Autoconfiguration works for hosts. It > provides a means for a network manager to make updates to the > prefixes used by and advertised by IPv6 routers throughout a site. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-10.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-router-renum-10.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-router-renum-10.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-scoping-arch-00.txt
by Thomas Trede 17 Mar '00

17 Mar '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, March 17, 2000 2:21 PM Subject: I-D ACTION:draft-ietf-ipngwg-scoping-arch-00.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 Scoped Address Architecture > Author(s) : S. Deering, B. Haberman, B. Zill > Filename : draft-ietf-ipngwg-scoping-arch-00.txt > Pages : 11 > Date : 16-Mar-00 > > This document specifies the architectural characteristics, expected > behavior, and usage of IPv6 addresses of different scopes > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-00.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-scoping-arch-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-ipngwg-scoping-arch-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. >

1 0

Fw: I-D ACTION:draft-ietf-ipngwg-addr-arch-v3-00.txt
by Thomas Trede 17 Mar '00

17 Mar '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Thursday, March 16, 2000 10:11 PM Subject: I-D ACTION:draft-ietf-ipngwg-addr-arch-v3-00.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 Addressing Architecture > Author(s) : R. Hinden, S. Deering > Filename : draft-ietf-ipngwg-addr-arch-v3-00.txt > Pages : 25 > Date : 15-Mar-00 > > This specification defines the addressing architecture of the IP > Version 6 protocol [IPV6]. The document includes the IPv6 addressing > model, text representations of IPv6 addresses, definition of IPv6 > unicast addresses, anycast addresses, and multicast addresses, and an > IPv6 node's required addresses. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-00.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-addr-arch-v3-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-ipngwg-addr-arch-v3-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. >

1 0

IPv6 Forum forges agreement with IBC
by nadim.chaudhry＠informa.com 15 Mar '00

15 Mar '00

Speaking Opportunities @ IPv6 The New Internet This is notice of the IPv6 New Internet conference which is taking place in London on June 22nd-23rd. The conference is being organised, with the full support of the IPv6 Forum, see below. This is a timely event which will examine the critical issue of IPv6 deployment. Please see the attached formal invitation for further information and the recent announcement from the IPv6 Forum below. This two day public conference will explore the business and technical case for IPv6 and include the latest product demonstrations in the dedicated IPv6 Exhibition area. There are still a few outstanding opportunities to present papers and also take up an exhibition opportunity. Should you wish to either submit a presentation or receive more details about the exhibition then please e-mail nadim.chaudhry(a)informa.com. Regards Nadim IPv6 Forum forges agreement with IBC Dear IPv6 Forum Members, IBC, Europe's largest conference organiser and founder of the mega GSM World Congress 10 years ago - http://www.gsmworldcongress.com/ and the IPv6 Forum have agreed in principal to organise during 2000 and 2001 a series of conferences to promote IPv6 and where IPv6 Forum members can have access to and speak in: IPv6 : The New Internet London: June 23-25, 2000 A committee will be set up to design the agenda. Join me to thank Peter and Thomas for holding the IPv6 flame for us! Cheers to IPv6! /Latif Ladid IPv6 Forum Regards Mr Nadim Chaudhry Research Manager IBC Telecoms Division Informa Telecoms Group nadim.chaudhry(a)informa.com Tel:+44-171-453-2025 Fax:+44-171-636-1976 Postal Address: 57-61 Mortimer Street, London W1N 8JX, UK This is an Email from the Informa Group. Its contents are confidential to the intended recipient at the Email address to which it has been addressed. It may not be disclosed to or used by anyone other than this addressee, nor may it be copied in any way. If received in error please contact The Informa Group on 0171-637-4383 (UK) or +44-171-637-4383 (International) quoting the name of the sender and the addressee, then delete it from your system. Please note that neither The Informa Group nor the sender accepts any responsibility for viruses and it is your responsibility to scan attachments (if any)

1 0