- ipv6-wg - mailman.ripe.net

final agenda for IPv6 working group RIPE36
by David Kessens 12 May '00

12 May '00

Hi, Below follows the final version of the IPv6 wg agenda. Please let me know if you have any other topics that you want to have discussed or if you have other comments. Despite being the final version of the agenda, we still have the freedom to add more topics during the agenda bashing. I am still looking for volunteers to cover some of the topics as proposed in the agenda. Please let me know if you are willing to take care of one of these. I have asked for a one hour time slot this time since we are already providing an IPv6 tutorial on tuesday (see RIPE NCC website for details). In addition, Bill Manning will give a presentation on DNS and IPv6 to the dns working group. In order to allow you to attend this presentation, I have asked the meeting organization to make sure that the DNS working group session and IPv6 working group session will not fall into the same time slot. At this point I still haven't heard whether the registries will be ready before the meeting with the draft revision of the IPv6 allocation guidelines. I will try to get more time allocated to us and the local ir working group in case they are able to get the draft out just before the meeting. Thanks and see you at the meeting, David K. --- Agenda for the IPv6 Working Group Meeting RIPE36, May 2000, Budapest A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of 6bone (David Kessens) C. News from the IPv6 forum (Juergen Rauschenbach) D. Summary of the Birmingham IPv6 event (Stuart Prevost) E. European developments/initiatives regarding IPv6 (input from the audience) F. Reports on on-going projects, success & failures stories on IPv6 (I am looking for volunteers who are willing to share their experiences) G. Future plans for the working group (input from the audience) tutorials, topics for next meeting, call for volunteers Z. AOB ---

1 0

draft agenda (v1) for IPv6 working group RIPE36
by David Kessens 01 May '00

01 May '00

Hi, Below follows the first draft of the IPv6 wg agenda. Please let me know if you have any other topics that you want to have discussed or if you have other comments on this first draft of the agenda. I am still looking for volunteers to cover some of the topics as proposed in the agenda. Please let me know if you are willing to take care of one of these. I have asked for a one hour time slot this time since we are already providing an IPv6 tutorial on tuesday (see RIPE NCC website for details). In addition, Bill Manning will give a presentation on DNS and IPv6 to the dns working group. In order to allow you attend this presentation, I have asked the meeting organization to make sure that the DNS working group session and IPv6 working group session will not fall into the same time slot. At this point it is still unclear whether the registries will be ready before the meeting with the draft revision of the IPv6 allocation guidelines. I will try to get more time allocated to us and the local ir working group in case they are able to get the draft out in time. Thanks, David K. --- Proposed Agenda (draft v1) for the IPv6 Working Group Meeting RIPE36, May 2000, Budapest A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of 6bone (David Kessens) C. News from the IPv6 forum and meeting in Telluride (Juergen Rauschenbach/Thomas Trede ?!?) D. European developments/initiatives regarding IPv6 (input from the audience) E. Reports on on-going projects, success & failures stories on IPv6 (I am looking for volunteers who are willing to share their experiences) Z. AOB ---

1 0

Fw: New version of "Mobility Support in IPv6" draft
by Thomas Trede 28 Apr '00

28 Apr '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Dave Johnson" <dbj(a)cs.cmu.edu> To: <mobile-ip(a)standards.nortelnetworks.com>; <ipng(a)sunroof.eng.sun.com> Sent: Thursday, April 27, 2000 8:57 PM Subject: New version of "Mobility Support in IPv6" draft > I just submitted a revised version of the Internet-Draft "Mobility > Support in IPv6", which corrects a number of minor problems and adds > several clarifications over the previous version of the draft. Here > is a list of some of the changes since the previous version: > > - Moved the definition of IPsec requirements for Binding Updates > and Binding Acknowledgements to Section 4.4), giving this > important information its own specific section with a section > title (IPsec Requirements for Mobile IPv6 Destination Options) > that will be identifiable in the table of contents for this > document. This makes these requirements harder to miss than > where they were defined in Sections 5.1 and 5.2, mixed in with > the definition of the format of these destination options. > > - In Section 4.6, added a precise definition of Sequence Number > value comparison modulo 2**16. Also added a reference to this > definition in each other place where Sequence Number comparison > is discussed. > > - Added a statement in Section 9.5 to clarify the sending of a > Neighbor Advertisement message by the home agent on behalf of the > mobile node in order to intercept packets addressed to the mobile > node. Except for the specific fields defined there, all fields > in each such Neighbor Advertisement SHOULD be set in the same > way they would be set by the mobile node itself if sending this > Neighbor Advertisement while at home [17]. > > - In Section 10.6, specified that the Lifetime in the Binding > Update sent by a mobile node to its home agent SHOULD be less > than or equal to the remaining lifetime of the home address and > the care-of address specified for the binding. > > - In Section 10.8, modified the specification that was there > about the correct setting of the Lifetime in the Binding > Update sent by a mobile node to a correspondent node. The > original specification stated that the Lifetime value MUST be no > greater than the remaining lifetime of the mobile node's home > registration of its primary care-of address at its home agent. > However, there should be no necessary relationship between the > remaining lifetime of a home registration and the lifetime of > a binding at a correspondent node. Instead, as with the home > registration Binding Update, the Lifetime in the Binding Update > sent by a mobile node to a correspondent node SHOULD be less than > or equal to the remaining lifetime of the home address and the > care-of address specified for the binding. > > - In Section 5.4, added a statement that a packet MUST NOT contain > more than one Home Address option, except that an encapsulated > packet [4] MAY contain a separate Home Address option associated > with each encapsulating IP header. > > - In Section 4.6, added a new field in the Binding Update List > entry format to record the initial value of the Lifetime field > sent in that Binding Update. > > - In Section 10.12, defined a new step in processing a received > Binding Acknowledgement: if the value specified in the Lifetime > field in the Binding Acknowledgement is less than the Lifetime > value sent in the Binding Update being acknowledged, then the > mobile node MUST subtract the difference between these two > Lifetime values from the remaining lifetime for the binding > as maintained in the corresponding Binding Update List entry. > The effect of this step is to correctly manage the mobile > node's view of the binding's remaining lifetime (as maintained > in the corresponding Binding Update List entry) so that it > correctly counts down from the Lifetime value given in the > Binding Acknowledgement, but with the timer countdown beginning > at the time that the Binding Update was sent. This change also > affected Section 10.8 in sending Binding Updates, to record both > the original lifetime and the remaining lifetime in the Binding > Update List. > > - In Sections 5.1 and 9.3, clarified that the Duplicate Address > Detection performed by the home agent if the Duplicate Address > Detection (D) bit is set in the Binding Update, is performed > before returning the Binding Acknowledgement for that Binding > Update. > > - In Section 5.1, clarified that the mobile node SHOULD set the > Duplicate Address Detection (D) bit in its home registration > Binding Updates based on any requirements for Duplicate Address > Detection that would apply to the mobile node if it were at > home [17, 27]. > > - In Section 9.3, specified that a home agent, when performing > Duplicate Address Detection for a mobile node when the > Duplicate Address Detection (D) bit is set in a received > Binding Update, SHOULD NOT delay sending the initial Neighbor > Solicitation message of Duplicate Address Detection by the random > delay specified for normal processing of Duplicate Address > Detection [17, 27]. > > - In Section 10.5, defined special considerations for a mobile > node's use of Duplicate Address Detection upon forming a new > care-of address. In particular, the mobile node MAY begin > using the new care-of address without performing Duplicate > Address Detection, and MAY optionally bypass Duplicate Address > Detection or begin Duplicate Address Detection asynchronously > when it begins use of the address, allowing the Duplicate > Address Detection procedure to complete in parallel with > normal communication using the address. In addition, the > mobile node SHOULD NOT delay sending the initial Neighbor > Solicitation message of Duplicate Address Detection by the random > delay specified for normal processing of Duplicate Address > Detection [17, 27], unless the mobile node is initializing after > rebooting. > > - In Section 4.6, added a clarification to the definition of the > Binding Update List, that for multiple Binding Updates sent to > the same destination address, the Binding Update List contains > only the most recent Binding Update (i.e., with the greatest > Sequence Number value) sent to that destination. This was > already noted in previous versions of the draft in the sending of > Binding Updates, as defined in Section update-corresp, but was > not previously stated explicitly in the definition of the Binding > Update List conceptual data structure. > > - In Section 9.3, added a specification that the lifetime for the > Binding Cache entry (and thus the Lifetime value returned in the > Binding Acknowledgement) MUST NOT be greater than the Lifetime > value specified in the Binding Update. Also added a similar > specification (and clarification) in Section 8.3 for the Binding > Cache entry in a correspondent node. > > - In Section 10.6, added a clarification that, when sending a > Binding Update to its home agent, the mobile node MUST also > create or update the corresponding Binding Update List entry, as > specified in Section 10.8. > > The official announcement of the draft should appear on the mailing > lists shortly, but you can get a copy of the new draft now from > > http://www.monarch.cs.cmu.edu/internet-drafts/draft-ietf-mobileip-ipv6-12.tx t > > We expect to go to Last Call on this version of the draft shortly. > Please send any comments on the draft to the Mobile IP mailing list at > mobile-ip(a)standards.nortelnetworks.com. > > Thanks. > > Dave > > -- > David B. Johnson dbj(a)cs.cmu.edu > Associate Professor http://www.cs.cmu.edu/~dbj/ > Computer Science Department http://www.monarch.cs.cmu.edu/ > Carnegie Mellon University Phone: (412) 268-7399 > 5000 Forbes Avenue Fax: (412) 268-5576 > Pittsburgh, PA 15213-3891 > > -------------------------------------------------------------------- > 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: UNH Cthon, Forum results
by Thomas Trede 11 Apr '00

11 Apr '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Ray LaRocca" <rglr(a)iol.unh.edu> To: <ipng(a)sunroof.eng.sun.com> Cc: "Ray LaRocca" <rglr(a)iol.unh.edu> Sent: Monday, April 10, 2000 9:11 PM Subject: UNH Cthon, Forum results > Hello All, > > The following are the results of the UNH testing at Connectathon 2000 and > the IPv6 Forum meeting in Telluride. > > Connectathon 2000: > 1. 15 IPv6 implementations were present (5 times as many as last year) > 2. We tested Mobile IPv6, RIPng and BGP4+ interoperability (as well as > some conformance testing) > > IPv6 Forum, Telluride: > 1. 7 IPv6 implementations were present > 2 We tested RIPng, BGP4+, and tunneling interoperability (some conformance > testing here also) > > --------------------------------------------------------------- > Mobility testing at Connectathon: > --------------------------------------------------------------- > Participants: > ENST Bretagne, Ericsson, Ericsson-Telebit, Microsoft Research, NEC, Nokia > > Implementations present: > 5 home agents, 3 mobile nodes, 4 correspondent nodes > > Testing Highlights: > Approximately 20 interoperability tests were run over the course of the 3 > days of testing. We had a moderate level of interoperability even though > the implementations were in various stages of development (version 8, 9, > and 10 of the spec were present). The participants spent much of the time > debugging and modifying their code. > > Testing Topology: > 4 networks connected via a single mobile unaware v6 router. > > Testing Scenarios: > (A) > 1. A home agent, mobile node pair begin on the home network with a > correspondent node residing on a foreign network. > 2. The mobile node moves from the home network to a foreign network while > pinging the correspondent node. > 3. The mobile node then moves from a foreign network to another foreign > network continuing to ping the correspondent node. > 4. The mobile node then moves to the foreign network where the > correspondent node resides (still pinging) > 5. The mobile node returns home. > > (B) > The same as above except with a telnet session open between the mobile > node and the correspondent node. > > We were able to achieve success in both of the above scenarios. > > Issues/Questions: > 1. Versions 8, 9, and 10 of the spec were present. > 2. There were issues involving DAD when the mobile node returned home > (this has been addressed in version 11 of the spec) > 3. Issues with option ordering in the packet have also been addressed in > version 11 of the spec > 4. There was an implementation incorrectly detecting movement by detecting > the different EUI-64 of the router. In our setup the router was using the > same EUI-64 for each of its interfaces thus causing difficulty for that > implementation to detect movement. This issue was presented to Dave > Johnson and he has addressed this issue to the mobileip working group. > > What Next? > 1. We need to have an interoperability test event within 6 months to > include Mobile IPv4, DIAMETER, and Mobile IPv6, with IPsec interaction. (TBD) > 2. UNH IOL has developed Mobile IPv6 conformance tests and is currently > providing the testing service. > > --------------------------------------------------------------- > Routing and conformance testing at both Connectathon and IPv6 Forum > --------------------------------------------------------------- > Participants: 3Com, Cisco, COMPAQ, Ericsson-Telebit, HP, Hitachi, KAME, > Microsoft Research, NOKIA, Nortel, SCO, SGI, SUN > > RIPng: > 1. 14 implementations with nearly 100% interoperability > 2. Some minor issues that were implementation-specific > 3. The basic setup was all routers on the same network with some > configured routes being advertised. > 4. 1 question regarding advertising a prefix for a network on the actual > network was posted to the ipng mailing list. Implementations were doing > one of 3 things: advertise the prefix with metric 1, metric 16, or not > advertise it at all. > > BGP4+: > 1. 9 implementations with nearly 100% interoperability > 2. Some minor issues that were implementation-specific > 3. The basic setup was all routers on the same network establishing both > internal and external peer sessions with other routers. > > > --------------------------------------------------------------- > > > > > > > > > -------------------------------------------------------------------- > 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-site-prefixes-04.txt
by Thomas Trede 10 Apr '00

10 Apr '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Monday, April 10, 2000 1:34 PM Subject: I-D ACTION:draft-ietf-ipngwg-site-prefixes-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 : Site prefixes in Neighbor Discovery > Author(s) : E. Nordmark > Filename : draft-ietf-ipngwg-site-prefixes-04.txt > Pages : 22 > Date : 06-Apr-00 > > This document specifies extensions to IPv6 Neighbor Discovery to > carry site prefixes. The site prefixes are used to reduce the effect > of site renumbering by ensuring that the communication inside a site > uses site-local addresses. > This protocol requires that all IPv6 implementations, even those that > do not implement this protocol, ignore all site-local addresses that > they retrieve from the DNS when the AAAA or A6 RRset contain both > global and site-local addresses. If the RRset contains only site- > local addresses those addresses can be used. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-site-prefixes-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-site-prefixes-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-site-prefixes-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

Re: [FYI] announcement of NTT's IPv6 trial in Europe
by Juergen Rauschenbach 28 Mar '00

28 Mar '00

Dear Mr. Nomura, thank you very much - this is a great opportunity! I will cc this information to the IPv6Forums member list and to the RIPE IPv6 WG. Regards, Juergen Rauschenbach, DFN At 17:13 28.03.00 +0100, Kenji NOMURA wrote: >Dear Dr.Rauschenbach, > >FYI, NTT Europe made an announcement of global IPv6 commercial trial in >Europe. >Visit our web site which includes the press release as well. >http://ipv6.uk.ntt.net > >Regards, > ># Kenji NOMURA @ IP Task Force, NTT Europe Limited >

1 0

Fw: Request to Advance "Initial IPv6 Sub-TLA ID Assignments"
by Thomas Trede 28 Mar '00

28 Mar '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <narten(a)raleigh.ibm.com>; "Jeffrey Burgan" <burgan(a)corp.home.net> Cc: <scoya(a)ietf.org>; <deering(a)cisco.com>; <ipng(a)sunroof.eng.sun.com> Sent: Tuesday, March 28, 2000 3:10 AM Subject: Request to Advance "Initial IPv6 Sub-TLA ID Assignments" > Jeff, 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 > Informational RFC: > > Title : Initial IPv6 Sub-TLA ID Assignments > Author(s) : B. Hinden, S. Deering, B. Fink, T. Hain > Filename : draft-ietf-ipngwg-iana-tla-03.txt > Pages : 5 > Date : 14-Jan-00 > > This document was discussed at the Washington, DC IETF meeting and is being > submitted to document the initial IPv6 Sub-TLA ID assignments. > > 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: W.G. Last Call on "IP Version 6 Addressing Architecture"
by Thomas Trede 28 Mar '00

28 Mar '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <ipng(a)sunroof.eng.sun.com> Sent: Tuesday, March 28, 2000 3:04 AM Subject: W.G. Last Call on "IP Version 6 Addressing Architecture" > This is a IPng working group last call for comments on advancing the > following document as a Draft Standard: > > 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 > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end two > week from today on April 10, 2000. > > Bob Hinden / Steve Deering > > > -------------------------------------------------------------------- > 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

IPv6Forum Event 10th May, Birmingham, UK
by Prevost,SM,Stuart,NZD5 R 24 Mar '00

24 Mar '00

All, Please could you pass this on to anyone you may think would be interested in attending this event. If you require any further information please get in contact with me. BT is co-ordinating the next Global IPv6 Conference, details below, or see http://www.ipv6forum.com/ for the latest information. Registration forms can be obtained from http://www.wtc2000.org/ipv6reg.pdf (ï¿½150 before March 31, ï¿½200 after). Thanks, Stuart EVENT PROGRAM 9.00am Welcoming presentations Welcome to the UK IPv6 Summit - Steve Sim - BT and IPv6 Forum Board IPv6 Forum Presentation - Latif Ladid - IPv6 Forum President and Ericsson-Telebit 9.30am Key-Note Speakers The New Wave ISP- Chris Earnshaw - CTO BT The New Internet - Peter Kirstein - UCL European Strategic Initiatives - Mario Campolargo - Head of Research Networks, European Commision 10.45am Coffee 11.15am The Case for IPv6 IPv6 advantages- Yanick Pouffary - Compaq IPv6 transition scenarios and tools - Marc Blanchet - Viagï¿½nie 12.30pm Lunch and Demonstrations 2.00pm The Coming Tidal Wave IPv6 in the Mobile world - Egbert Jan Sol - CTO Ericsson Holland. IPv6 and UMTS - Asko Rasanen - Nokia Wiring the cities for IPv6 - Lasse Lindblad - Telia 3.15pm Coffee 3.45pm IPv6-Ready Platforms and Routers Directions in IPv6 Implementations - Martin McNeales - Cisco Porting applications to IPv6: simple and easy- Marc Blanchet - Viagï¿½nie 6INIT - The European IPv6 trial - Peter Hovell - BT 5.30pm Close 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

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