- ipv6-wg - mailman.ripe.net

RIPE29: IPV6 WG Agenda
by Thomas Trede 29 Dec '97

29 Dec '97

Hello, here comes the first draft for the agenda of the IPV6 WG at RIPE29. Please feel free to send comments/suggestions to me. But please be also aware of the fact that I will be on holiday until January 11th, 1998. Regards, Thomas Proposed Agenda for the IPV6 Working Group RIPE-29, Januar 1998, Amsterdam 1st Draft, 28.12.1997 1. Administrative stuff (Thomas Trede, chair) - volunteering of the scribe - agenda bashing 2. Reports - 6Bone - IETF, proceedings IPV6 - IPV6 Adressing Architecture: input/presentation by Rob Blokzijl and Daniel Karrenberg - News about manufacturers implementation - input from the audience (so prepare yourself !) 3. Current status of RIPE regarding address assignments in IPV6 - with input from RIPE NCC (if available/necessary) 4. General Input from other Working Groups 5. AOB

2 1

Lasers/Optics/Optical Tables - Save!
by StlM22Bdu＠m1Im.net 05 Dec '97

05 Dec '97

MWK INDUSTRIES SALE! JUST A QUICK LETTER TO SHOW YOU SOME LASERS- OPTICS AND OPTICAL TABLES SURPLUS THAT WE JUST RECEIVED. ITEM TRIMMU12 14 WATT ARGON LASER MADE FOR HEART SURGERY, TRIMEDYNE MODEL 900 TEMOO, POLORIZED,220VAC INPUT , WATER COOLED , FIBER LAUNCH, ALL ON ROLLAROUND CART EXCELENT FOR LAB USE, THE POWER WAS MEASURED AT 13 TO 14 WATTS. PRICE $9500 12 MONTH WARRANTEE. ITEM: COHERENT ARTICULATING ARM FROM A MODEL 451 CO2 MEDICAL LASER. ECCELLENT COND. $200 ITEM CO220A: CO2 LASER MADE BY PFIZER ,1990, FOR SURGERY, TATTOO REMOVAL ECT. 20 WATT OUTPUT , TESTED AND IN EXC. COND. 110 VAC INPUT, COST $40,000 NEW OUR PRICE 4,900. MODEL 20-C ITEM:PDA-1U1 SPECTRA PHYSICS QUANTRA RAY PULSED DYE LASER , GOOD FOR SPARE PARTS MODEL PDA-1 $500 ITEM NEWU1 NEWPORT OPTICAL TABLE 16" BY 36" 4" THICK, 1 " HOLE SPACING, COMES WITH A RUBBER ISOLATED TABLE STAND, NOT AIR SUPPORTED, $750 ITEM: HEPSN1 HELIUM NEON POWER SUPPLY KIT OPERATES UP TO A 15 mW LASER, INCLUDES ALL COMPONENTS AND PRINTED CIRCUIT BOARD, ALL YOU HAVE TO DO IS STUFF AND SOLDER THE CIRCUIT BOARD . 4" BY 3" BY 3", PRICE $75 ITEM HENEU12 1 TO 1.5 MW HE-NE LASER 632.8 nM INCLUDES 12VDC INPUT POWER SUPPLY ALL IN A PLASTIC HOUSING 6.25 IN. BY 1.375IN BY 2.25 IN. TEMOO,RANDOM POL. ,1.7 MR DIVERGENCE. 12 MONTH WARRANTEE , PRICE $45 ITEM MELU12 1 TO 2 mW HE-NE LASER 632.8 NM , PULLS FROM MEDICAL EQUIPMENT .EACH UNIT INCLUDES HE-NE HEAD AND POWER SUPPLY[110VAC INPUT]. ALL YOU NEED TO PROVIDE IS A POWER CORD AND A FUSE TO MAKE THE UNIT OPERATIONAL. THE BEAM IS TEM00, POLORIZED WE WILL COVER EACH UNIT WITH A 12 MONTH UNLIMITED HOUR WARRANTEE, EXCELLENT FOR FOR LAB OR HOME USE. NEW THESE COST APPROX. $350 OUR PRICE $85. DIMENSIONS 9.75 BY 1.25 INCHES, P.S. 4.25 BY 3.25BY 1.25 INCHES. ITEM RAMCNS1: RAMAN CELL OPTICS 308 nm AR/AR 4600 A 0=0 DEGREES 1000 MM FL. 2" DIA. NEW. ORIGINAL PRICE $520 OUR PRICE $175 ITEM TFPOLNS1: POLARIZERS , THIN FILM FOR 532 nm , NEW, ORIGINAL COST $590 EACH OUR PRICE $200 EACH 10 MM DIA. ITEM CO2OCNS1: CO2 HIGH REFECTOR AND OUTPUT COUPLER 10.5 MM DIA, OC =79%R NEW. $200 A SET. ITEM 25MNS1: DIELECTRIC BROADBAND MIRRORS 450 TO 700NM , NEW WITH PLASTIC PROTECTIVE COATINGS , 2 SIZES 25 MM SQ. AND 50 MM SQ. RECOMENDED FOR HIGHER POWER LASERS. 25MM SIZE ITEM 25MNS1 $20 50MM SIZE ITEM 50MNS1 $25 ITEM # BSDNS1: 50/50 DIELECTRIC COATED PLATE BEAM SPLITTER 630 TO 660 NM COMES IN A TRIANGLE SHAPE EACH SIDE APPROX. 1" PRICE $20 ITEM # 45NS1 45 DEGREE RED REFLECTOR , PASSES 488 TO 532NM , CAN BE USED TO COMBINE RED AND GREEN/BLUE LASERS TO CREATE A WHITE LIGHT LASER. 1" SQ. PRICE $15 ITEM# PCINS1 PLANO/CONVEX LENS COATED FOR YAG 1064NM , AR COATED, 10MM DIA. NEW, ORIG. COST $250 OUR PRICE $100 ITEM# INFILTER : INTERFERENCE FILTERS USED FOR PASSING A PARTICULAR SPECTRAL LINE , 11.8 MM DIA. CAREFULLY REMOVED FROM MEDICAL EQUIPMENT AND WRAPPED IN LENSE PAPER. THE FOLLOWING WAVE LENGTHS ARE AVAILABLE. 523.5, 547.4 , 572.1, 512.9, 550.6, 488, 505.7 nm price $20 each. FOR A COMPLETE LINE OF NEW AND USED LASERS - OPTICS -ELECTRO OPTICS- LASER SHOWS ORDER A COMPLETE CATALOG AT MWKINDUSTRIES.COM TO: ORDER GO TO OUR WEB SITE MWKINDUSTRIES.COM {SECURE ORDERING SITE} QUESTIONS OR REMOVAL FROM MAILING LIST EMAIL: MWK(a)WORLDNET.ATT.NET MWK INDUSTRIES 1269 POMONA RD CORONA CA 91720 PHONE 909-278-0563 FAX 909-278-4887

1 0

Re: (IPng 5002) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard
by huitema＠bellcore.com 04 Dec '97

04 Dec '97

On Dec 2, 4:48am, bmanning(a)isi.edu wrote: > In short, I differ from Mike in that my values for "believed to be viable" > differ, apparently wildly, from his and brians. I'm unconvinced that > this will remain a true, long term technological argument. I'd like to > see something besides, "too hard with 1990's technologies". "Long time" > ought to have a better spec than say, Internet Dog Years? Bill, What you say is true. Technology is going to progress, and at some point in the future we may convince ourselves that we can safely handle 1,000,000 TLAs instead of 10,000. However: 1) We are not there yet. Andrew Brodnik et al demonstrated that one can efficiently compress today's routing tables in the cache of a Pentium chip. But their algorithm has yet to be implemented in commercial routers. 2) There is more to scaling than routers' caches. Compressing the tables in cache memory mainly allows you to switch packets faster than if your tables were kept in a slow RAM. It does not reduce route flaps, or the complexity of the topology. 3) In any case, we are taking decision today based on today's technology. As I pointed out, there is plenty of address space reserved for further use. If the technology does evolve, then it will be time to open more space. In short, limiting the size of TLA to 13 bits looks like a reasonable cut, today. -- Christian Huitema

4 3

Re: (IPng 4984) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard
by Scott Bradner 02 Dec '97

02 Dec '97

Daniel said: I have seen some of this discussion. I am afraid I have seen no documented discussion revealing the reasoning behind fixing the TLA length and fixing it at 13 bits. Frankly I have been surprised by the sudden speed of the provider based addressing standardisation. last year in regards to what is now RFC 2050 I asked the lawyers that do work for the IESG what restrictions in flexibility we (the IETF) have in the area of defining rules and technology that restricts ISP practices. I was told that the only time we can be restrictive is when there is no other technically reasonable option - I support Daniel here, if this field is to be restricted to a specific length then we must have very good technical reasons for doing so. Scott

4 6

Re: Minutes of the IPv6 WG at RIPE 27 and 28
by Alain Durand 02 Dec '97

02 Dec '97

On Nov 30, 12:08am, Thomas Trede wrote: > Subject: Minutes of the IPv6 WG at RIPE 27 and 28 > > Hello, > > the draft minutes for the IPv& WG at RIPE 27 and 28 have been circulated > on the mailing list and are published at www.ripe.net. > If someone has comments or changes, please give me a feedback. > If there are no comments or request for changes up to the 10th of December > 1997, the status will be advanced from "draft" to "final" I was not at this RIPE meeting, but I have received the following message from Daniel Karrenberg and Robert Blokzijl (speaking in the name of RIPE and RIPE-NCC) as a response to an IESG last call. I would like to know if this subject was discussed or not at RIPE IPv6 WG and if this statement reflect the position of this WG, - Alain Durand. ^_^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ U (* *) Alain DURAND | Preserve keyboards: | ( v ) I.M.A.G. | use completion. | /~~~\ Direction des Moyens Informatiques |----------------------------- <|=< IP >= BP 53 38041 Grenoble Cedex 9 | E-Mail: Alain.Durand(a)imag.fr | \ v6/ France | Phone: +33 4 76 63 57 03 | <~~< Postmaster(a)imag.fr | Fax: +33 4 76 51 49 64 ~ ~ On Nov 26, 6:05pm, Daniel Karrenberg wrote: > Subject: (IPng 4984) Re: Last Call: IP Version 6 Addressing Architecture t > To: iesg(a)ietf.org > > > Authors > > Robert Blokzijl > RIPE Chair > > Daniel Karrenberg > RIPE NCC General Manager > > > Background > > RIPE is an organisation founded in 1989 wich aims to ensure the > technical and administrative coordination necessary for the operation of > the Internet in Europe [ripe-01]. > > The RIPE NCC performs activities for the benefit of the Internet service > providers (ISPs) in Europe and the surrounding areas; primarily > activities that the ISPs need to organise as a group, although they may > be competing with each other in other areas. In particular the RIPE > NCC, as Regional Internet Registry, allocates and assigns IPv4 address > space in Europe and surrounding areas [ripe-162]. The RIPE NCC started > operations in 1992. It currently allocates address space to more than > 800 local Internet Registries almost all of which are operated by ISPs. > The number of local IRs is expected to reach 1250 in 1998. There are > currently no indications that the number of local IRs will stop growing. > > The authors have contributed significantly to the development of the > distributed Internet registry system which is used for the allocation > and assignment of provider based IPv4 address space today. As such they > have ample experience with the development of address space allocation > and assignment policies. One important element of current policies is > that the size of address space allocations is determined by previous > justified use of address space. A prerequisite for this policy is that > the size of allocations can start small and increase or decrease > according to previous justified usage [ripe-159]. > > > Argument > > We believe <draft-ietf-ipngwg-unicast-aggr-02.txt> is critically flawed > because it standardises address aggregation boundaries without any > explicit technical justification. In particular the length of the TLA > and NLA fields are proposed to be standardised as fixed at prarticular > values with no technical justification for either the fact that these > lengths need to be fixed nor for the particular values chosen. The lack > of technical justification is significant because the standardisation of > TLA and NLA lengths directly influences many elements of Internet > operations including address space allocation policies. In particular > the TLA being fixed at 13bit length makes only 8K TLAs available per FP. > Consequently Internet Registries will not be able to use proven > allocation policies but rather engage in regulatory practises. The > rules proposed in <draft-ietf-ipngwg-tla-assignment-01.txt> are clear > evidence of this. Broad acceptance of such rules and their implementation > is extremely unlikely unless there is convincing technical reasoning > behind the constraints that necessitate the rules. > > Because of this critical flaw we request that the IESG not advance > <draft-ietf-ipngwg-unicast-aggr-02.txt> and > <draft-ietf-ipngwg-addr-arch-v2-05.txt> to proposed standard yet. We > suggest that the IESG refer these documents back to the authors and the > WG with the request to provide technical justification for the placement > of aggregation boundaries and to consider making these boundaries > variable where technically feasible. > > > References > > The referenced RIPE documents can be accessed at > > http://www.ripe.net/docs/ripe-xxx.html HTML > ftp://ftp.ripe.net/ripe/docs/ripe-xxx.txt ASCII > ftp://ftp.ripe.net/ripe/docs/ripe-xxx.ps PostScript > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- >-- End of excerpt from Daniel Karrenberg

3 3

Re: (IPng 4997) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard
by huitema＠bellcore.com 01 Dec '97

01 Dec '97

Daniel, There were two basic arguments for limiting the length of the TLA prefix: 1) Routing table size. All TLA have to be in all tables in all defaultless routers. Thus, the number of TLAs becomes a minorant of the size of the tables. 2) Address space size. The current document only specifies 1/8th of the address space. If it turns out that there is a need for many more TLA's in three years, it will actually be possible to make some. The particular value chosen, 13 bits, as only one advantage. The combination of format and TLA fits in 16 bits, which provides for easy writing of routing prefixes. The point that you note re: allocation practices is, however, perfectly true. ISPs should not receive a TLA 'a priori", they should graduate to it. If I remeber correctly, an ISP that starts operating in Europe today receives a /19, and will gradually receive more space as it connects more customers. An ISP that starts operating with IPv6 should receive one or several NLAs from established transit providers; it should only receive a global entry in the routing tables once it has passed some "graduation" criteria. -- Christian Huitema

1 0

Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard
by Daniel Karrenberg 01 Dec '97

01 Dec '97

Authors Robert Blokzijl RIPE Chair Daniel Karrenberg RIPE NCC General Manager Background RIPE is an organisation founded in 1989 wich aims to ensure the technical and administrative coordination necessary for the operation of the Internet in Europe [ripe-01]. The RIPE NCC performs activities for the benefit of the Internet service providers (ISPs) in Europe and the surrounding areas; primarily activities that the ISPs need to organise as a group, although they may be competing with each other in other areas. In particular the RIPE NCC, as Regional Internet Registry, allocates and assigns IPv4 address space in Europe and surrounding areas [ripe-162]. The RIPE NCC started operations in 1992. It currently allocates address space to more than 800 local Internet Registries almost all of which are operated by ISPs. The number of local IRs is expected to reach 1250 in 1998. There are currently no indications that the number of local IRs will stop growing. The authors have contributed significantly to the development of the distributed Internet registry system which is used for the allocation and assignment of provider based IPv4 address space today. As such they have ample experience with the development of address space allocation and assignment policies. One important element of current policies is that the size of address space allocations is determined by previous justified use of address space. A prerequisite for this policy is that the size of allocations can start small and increase or decrease according to previous justified usage [ripe-159]. Argument We believe <draft-ietf-ipngwg-unicast-aggr-02.txt> is critically flawed because it standardises address aggregation boundaries without any explicit technical justification. In particular the length of the TLA and NLA fields are proposed to be standardised as fixed at prarticular values with no technical justification for either the fact that these lengths need to be fixed nor for the particular values chosen. The lack of technical justification is significant because the standardisation of TLA and NLA lengths directly influences many elements of Internet operations including address space allocation policies. In particular the TLA being fixed at 13bit length makes only 8K TLAs available per FP. Consequently Internet Registries will not be able to use proven allocation policies but rather engage in regulatory practises. The rules proposed in <draft-ietf-ipngwg-tla-assignment-01.txt> are clear evidence of this. Broad acceptance of such rules and their implementation is extremely unlikely unless there is convincing technical reasoning behind the constraints that necessitate the rules. Because of this critical flaw we request that the IESG not advance <draft-ietf-ipngwg-unicast-aggr-02.txt> and <draft-ietf-ipngwg-addr-arch-v2-05.txt> to proposed standard yet. We suggest that the IESG refer these documents back to the authors and the WG with the request to provide technical justification for the placement of aggregation boundaries and to consider making these boundaries variable where technically feasible. References The referenced RIPE documents can be accessed at http://www.ripe.net/docs/ripe-xxx.html HTML ftp://ftp.ripe.net/ripe/docs/ripe-xxx.txt ASCII ftp://ftp.ripe.net/ripe/docs/ripe-xxx.ps PostScript

2 3

Minutes of the IPv6 WG at RIPE 28th
by Bernard.Tuy＠urec.cnrs.fr 30 Nov '97

30 Nov '97

---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 14 Hi everybody, Here enclosed a proposal for the minutes of the IPv6 WG at the RIPE 28th meeting held in A'dam on last September. Comments, additions, corrections please to me directly :tuy@urec.fr Thanx for your careful reading and help, Regards, +Bernard Tuy. ---------- X-Sun-Data-Type: default X-Sun-Data-Name: IPv6-wg X-Sun-Charset: us-ascii X-Sun-Content-Lines: 114 OD: CNRS/U.R.E.C Tx: B. Tuy Dt: 20.10.1997 NV: 1.0 ------- Minutes from the RIPE IPv6-wg ** DRAFT ** Chairman : Thomas Trede, Nacamar, Germany Scribe : Bernard Tuy, UREC, France Attendance: xx persons present Agenda : sent to the mailing list before the meeting Reports . 6bone (F. Dupont) Presenting 6bone maps (sites and core) more than 120 sites are now connected to the 6bone (representing #30 countries) A new addressing scheme (cf related IETF IDs at http://playground.sun.com) is being to be deployed. Top Level Aggregators (in fact, pseudo TLAs) have begun to be allocated to people matching the conditions to get one. The pseudo TLAs (pTLAs) list is available at http://www.6bone.net/6bone_pTLA_list.html As an example the aggregated addressing plan in France is shown. To a question from BT : 4 people claimed to be deploying this aggregated plan, many are connected to the 6bone and less are using IPv6 ... ! . IPv6 Registry (D. Kessens) fully operational yet (whois.6bone.net) miror sites : whois.nic.fr and whois.ra.net 26 countries are now registered One can find a new whois client able to solve external references at www.isi.edu/~davidk/6bone/ Inet-num-ipv6 object attributes : (refer to David's Internet Draft for the syntax to use to fill every attribute) ipv6-site : prefix: multiple if needed application : apps running at that site tunnel: multiple if needed to describe the topology of the site contact: NIC-handle from RIPE, InterNIC or 6bone-NIC ... url: how to get more info on this site Test address allocation: same object as in IPv4 except the inetnum label ! . Last IETF meeting (Munich, Germany, Aug. 1997) (Francis Dupont) NGtrans-wg : see the minutes of the meeting already sent by email . tools : the translation between IPv4 and IPv6 headers (NAT,...) is under discussion, various solutions are being considered. Cisco has an implementation (the S/w is available from P. Marques) . 6bone : a new domain has been set up (6bone.net) BGP4+ is getting the consensus. Strong opposition from Cisco to BGP5 Implemented by : Cisco, Digital, GateD, Telebit Core backbone sites of the 6bone as to move to the new aggregated addressing scheme before Dec 1st. IPng-wg : see the minutes of the meeting already sent by email . Advancing the IPv6 specifications and related documents to standards . large discussion with the flow label identifier (why and how to use it ?), still open over the mailing list . strong consensus for the MTU specifications (minimal is moving from 576 to 1300) ION-wg : . G. Armitage proposal is the only one today using MARS for multicasting, NHRP for external routing and Neighbor Discovery for local routing. NBMA's are limited to ATM only today IDR-wg : BGP4+ will replace RIPng in the core backbone, before the end of the year. IPSEC-wg : New drafts are expected, since the 182x serie seems to be obsolete Multicast : no consistent progress except we have to have new specs based on the new IGMPv2 RFC. Implementations : refer to the SUN web page (http://playground.sun.com/pub/ipng/html/ipng-implementations.2.html) RIPE IPv6 address assignment : Noone in the audience claimed to need an IPv6 address space allocated yet. Other wg's input : DNS ? ____ EoF.

2 1

Re: Draft Agenda for IPV6-Working Group at RIPE28 Meeting
by Bernard.Tuy＠urec.cnrs.fr 19 Sep '97

19 Sep '97

| Date: Wed, 17 Sep 1997 23:57:59 +0200 (CEST) | From: Thomas Trede <tom(a)nacamar.de> | | Proposed Agenda for the IPV6 Working Group | | RIPE-28, September 1997, Amsterdam | | 1st Draft, 17.9.1997 | | | 2. Reports | | - 6Bone | - presentation by Francis Dupont ====BT: It seems to me that it's quite mandatory to discuss, under this topic, the new addressing scheme that is to be deployed in the 6bone core and 6bone connected test sites these days. But I'm confident Francis is well aware of this. | | - IETF, proceedings IPV6 | - presentation by Francis Dupont | | - News about dynamic routing protocols | - BGP 4 Plus | | - News about manufacturers implementation | - input from the audience (so prepare yourself !) | | 3. Current status of RIPE regarding address assignments in IPV6 ====BT: have you asked someone from the NCC to chair this item ? | | 4. General Input from other Working Groups | | - Database Working Group: IPV6 object ====BT: and what about DNS-wg ? Thank you for your attention. Regards, +Bernard Tuy.

4 3

2nd Draft Agenda
by Thomas Trede 18 Sep '97

18 Sep '97

Hello, please find enclosed the 2nd Draft Agenda for IPV6-WG. Regards, Thomas Proposed Agenda for the IPV6 Working Group RIPE-28, September 1997, Amsterdam 2nd Draft, 18.9.1997 1. Administrative stuff (Thomas Trede, chair) - volunteering of the scribe - agenda bashing 2. Reports - 6Bone - presentation by Francis Dupont - new addressing scheme to be deployed in the 6bone - status report on the 6bone registry including an overview of the new objects, by David Kessens - IETF, proceedings IPV6 - presentation by Francis Dupont - News about dynamic routing protocols - BGP 4 Plus - News about manufacturers implementation - input from the audience (so prepare yourself !) 3. Current status of RIPE regarding address assignments in IPV6 - with input from RIPE NCC 4. General Input from other Working Groups - Database Working Group: IPV6 object - DNS Working Group 5. AOB

1 0