- ipv6-wg - mailman.ripe.net

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

RIPE27: minutes, draft
by Thomas Trede 18 Sep '97

18 Sep '97

Hello, with delay here are finally the draft minutes of IPV6-WG odf RIPE 27. Regards, Thomas Minutes of the RIPE 27 IPv6 working group thursday may 27 The meeting is chaired by Francis Dupont. The chair excused himself before the meeting. Agenda: 1: Administrative stuff 2: Reports - 6Bone - IETF - routing - Implementations 3: RIPE and address assignment 4: Other WG - IPv6 DB object 5: Any other business 1: Administrative stuff The audience has no additions to the Agenda 2: Reports - 6Bone Francis gives a short overview of the current status of the 6Bone. He refers to the information on www.6bone.net for more detailed information. - IETF Francis gives a short overview of what happened at the IETF meetings on IPv6 - After long discussions the proposal by Mike O'Dell on addressing schemes (8+8, JSE) has been withdrawn by himself. There is now a new draft on addressing: draft-ietf-ipngwg-unicast-aggr-00.txt This draft proposes a addressing scheme that is optimized for aggregation. This draft is supposed to replace RFC2073 on provider based addressing. - Routing Currently there are draft proposals and beta implementations for three dynamic routing protocols with support for IPng. RIPng, there is an RFC and is widely used on the 6Bone OSPFng, there is a draft proposal. BGP4+, there is a draft proposal by Tony Bates from Cisco and there is a beta implementation by Cisco already implemented and running on core routers in the 6Bone. - Implementations No news on new implementations - RIPE and address assignment. [Francis I couldn't here what you had to tell here !!! ] - Other WG - DB The Ipv6 DB object. Francis stresses the importance of the RIPE IPv6 registration database since routing on the 6Bone is still not as dynamic as we would like. - AOB According to Francis Dupont there has been a IPv6 demonstration at the last JENC conference in Edinburg. On his question to the audience if anybody had seen this and could tell something about it, nobody reacted.

1 0

Draft Agenda for IPV6-Working Group at RIPE28 Meeting
by Thomas Trede 17 Sep '97

17 Sep '97

Hello, here is the first draft agenda for the upcoming RIPE Meeting. Comments/Suggestions welcome. Regards, Thomas Proposed Agenda for the IPV6 Working Group RIPE-28, September 1997, Amsterdam 1st Draft, 17.9.1997 1. Administrative stuff (Thomas Trede, chair) - volunteering of the scribe - agenda bashing 2. Reports - 6Bone - presentation by Francis Dupont - 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 4. General Input from other Working Groups - Database Working Group: IPV6 object 5. AOB ------------------------------------------------------------------- Thomas Trede NACAMAR Data Communications Senior Network Engineer P.O.Box 102262 63268 Dreieich / Germany e-mail: trede(a)nacamar.net voice: +49-6103-993-910 www : www.nacamar.net fax : +49-6103-993-999 -------------------------------------------------------------------

1 0