- ipv6-wg - mailman.ripe.net

Proposed agenda for IPV6-WG at RIPE-26
by Thomas Trede 12 Jan '97

12 Jan '97

Hello folks, here comes the first proposal for the IPV6-WG agenda for the next RIPE meeting. Regards, Thomas Proposed Agenda for the IPV6 Working Group RIPE-26, January 1997, Amsterdam 1st Draft, 11.1.1997 1. Administrative stuff (T. Trede, chair) - volunteering of the scribe - co-chairs - agenda bashing 2. Reports - 6Bone connectivity - News about manufacturers implementation 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 Frankfurter Strasse 135-141 63303 Dreieich / Germany e-mail: trede(a)nacamar.net voice: +49-6103-9901-0 www : www.nacamar.net fax : +49-6103-9901-18 -------------------------------------------------------------------

2 2

proposal for RIPE's IPv6-address space structure
by JOIN Project Team 26 Nov '96

26 Nov '96

Hello, we want to present a proposal concerning the allocation of IPv6-address space within the RIPE-region on the basis of the Internet Draft "An IPv6 Provider-Based Unicast Address Format" [1], which itself is consistent with RFC 1884 [2] and RFC 1887 [3]. The proposal is based on the following assumptions. A1. There will likely be a mixture of providers of different sizes. A2. Small providers will grow to become large providers. A3. Large providers will lose customers and become small providers. A4. Organizations which need to be multi-homed to more than one provider will request a Provider ID assignment. These four assumptions are essentially taken from [1] (see section 3.3). We add one further assumption: A5. Internet Service Providers will mainly offer their service within one country. Our proposal tries to achieve the following goals: D1. The hierarchical address structure is to simplify routing or rather to offset the growth of routing tables. (Aggregation) D2. Address space should be sufficient for a long time - in principle for ever. This leads to a conservative approach. (Conservation) D3. It should accommodate ISPs and their customers (avoid reassignments, if possible; long-term address space planning for providers). D2 and D3 are contrary in a way. We propose the following address allocation scheme: |FP+RegID| Provider ID | Subscriber ID | Intra-Sub | | | PRID | RPID | | | +--------+-------+------+---------------+-----------+ | 8 bit | 7 bit | n bit| (49 - n) | 64 bit | +--------+-------+------+---------------+-----------+ with n = 17 ! PRID (Provider Region ID) 7 bit corresponds to 128 IDs. These are mainly reserved for the countries of the 'natural', ie. European, RIPE-Region (A5). Non-European domains supported by RIPE get their own prefix (FP+RegID) in order to support a dedicated authority for these regions in the future. We should mention that we have discussed the possibility to subdivide the RIPE address space in such a way that the length of the Country-ID depends on the size (population) of that country. In such a scheme big countries could get a 5 or 6 bit long Country-ID (instead of 7 bit), resulting in a larger address space for those countries. RPID (Rest of Provider ID): In principle 56 bit are available to address providers and their customers. With n=17 there is room for 2^17 (= 131072) providers per provider region (=country). The remaining 32 bits are available to identify a customer. Hence, each provider has as many customer networks available as there are host addresses available with IPv4. If this turns out not to be enough to satisfy the needs of a very LARGE provider then, there should be the option to double the assigned address space by adjoining the neighboring address block. In order to do so RPIDs should be assigned in multiples of 16 initially, leaving the option to half the 'reserved' address space but still keeping the option to double. Given a reasonable size for an ISP within an open market this compromise should address D2 as well as D3 still leaving the option for some degenerated cases with just a single prefix. Different assumptions about the future growth and dynamics of national Internet markets might result in a different choice for n. We hope that this proposal will serve at least as input for discussion. References: [1] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., Postel, J., "An IPv6 Provider-Based Unicast Address Format", Internet Draft, March 1996. [2] Hinden, R., "IP Version6 Addressing Architecture", RFC 1884, December 1995. [3] Rekhter, Y., Li, T., "An Architecture for IPv6 Unicast Address Allocation", RFC 1887, December 1995. Best regards Frank Hoffmeister Guido Loeffler Juergen Rauschenbach Author's Addresses: Frank Hoffmeister EUnet Deutschland GmbH Phone: +49 231 972 00 Emil-Figge-Str. 80 Fax: +49 231 972 1188 D-44227 Dortmund E-Mail: Frank.Hoffmeister(a)Germany.EU.net Guido Loeffler JOIN project University of Muenster Phone: +49 251 83 8458 Einsteinstr. 60 Fax: +49 251 83 2678 D-48149 Muenster E-Mail: join(a)uni-muenster.de Juergen Rauschenbach DFN-Verein Phone: +49 30 884299 46 Pariser Str.44 Fax: +49 30 884299 70 D-10707 Berlin E-Mail: jrau(a)dfn.de

7 17

Re: proposal for RIPE's IPv6-address space structure
by Matt Fakray 25 Nov '96

25 Nov '96

> To: JOIN Project Team <join(a)uni-muenster.de> > Cc: ipv6-wg(a)ripe.net, lir-wg(a)ripe.net, > Frank Hoffmeister <Frank.Hoffmeister(a)germany.eu.net>, > ipv6(a)froggle.germany.eu.net, Juergen Rauschenbach <jrau(a)dfn.de> > Subject: Re: proposal for RIPE's IPv6-address space structure > From: Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> > Date: Fri, 22 Nov 1996 16:01:56 +0100 > > > JOIN Project Team <join(a)uni-muenster.de> writes: > > > Can you provide a rationale for grouping providers by country. > > > It strikes me as contrary to both aggregation and conservation goals. > > > > We assume that ISPs will mainly offer their service within one country. > > This is not necessarily a valid assumption. IBM offers Internet services in most European countries. It is not valid to assume that ISPs offer service mainly in one country. Ideally we would like to be given either a large block or multiple smaller ones so we can assign a block to each country and perform route summarisation internally within our OSPF cloud.

3 3

Re: proposal for RIPE's IPv6-address space structure
by Neil Harris 23 Nov '96

23 Nov '96

>Daniel Karrenberg writes: > > > > How about just using the 56 bits for local-IR+subscriber? > > The boundary does not need to be fixed at all. > > Then use a similar scheme than the present IPv4 one to determine the > > size of allocations to local IRs (provider): > > Fixed size for new local IRs and further allocations based on > > established usage rate. > > >Using only 56 bits for the IR would effectively defeat the possiblity >of using MAC / ESI addresses as the low 48 bits of an IP address. > >Pete Not to mention ESI and 1-byte selector, as is usual for ATM NSAP addressing, if we want to mix-and-match NSAP and IPv6 addresses. At Sohonet we are currently working out our NSAP addressing scheme. We have 4.5 bytes of prefix under the UK DCC scheme, and we add another nibble to define an 'escape hatch' version number for our numbering scheme, and bring it to byte alignment. We also have 6 bytes of ESI, and 1 byte of SEL, from common ATM practice. So, we now have only 20 - (4.5 + 0.5 + 6 + 1) = 8 bytes of NSAP address space left for our own internal purposes. We would very much like to have an addressing scheme where IPv6 and NSAP addresses can, at the very least, be derived algorithmically from one another. Our design criteria for our NSAP addressing scheme: > >The proposed addressing proposal should allow: > > Easy interpretation by human beings (eg byte aligned or nibble-aligned >fields) > A version field, to allow changing the numbering scheme later. > Compatibility with IPv6, if possible. > Easy NSAP filtering by _organisation_ and class of service, bearing in > mind that some filtering may only be possible by strict prefix. > Efficient routing > Support of multiple providers, multi-homing and diverse routing. > Some customer-specified numbering for internal use (???) -- Neil Harris Sohonet Limited http://www.sohonet.co.uk/

1 0

IPv6 demo at JENC7, Budapest
by JOIN Project Team 15 May '96

15 May '96

Hello, I would like to inform you about our IP version 6 demonstration at the JENC7 (Joint European Networking Conference) May 13-16 in Budapest, Hungary: We have setup an IPv6 test network in Budapest connected to the Danish research network DENet and to our IPv6 lab at the University of Muenster in Germany. For the demo we use routers from the Danish company Telebit Communications A/S and Suns running IPv6 for Solaris 2.5 (release 4.0). In Budapest we connected two Telebit routers via a 34 mbps ATM link running IPv6 over ATM and exchanging routing information with IDRPv6. One router in Budapest is connected to the IPv6 networks in Germany and Denmark using static configured IPv6 tunneling (over IPv4 internet) and exchanging routing information also using IDRPv6. We use both IPv4 compatible IPv6 addresses and full IPv6 addresses according to RFC1897. So with this setup we provide full native IPv6 connectivity using the RFC1897 test address space to the applications included in the Sun software... We have included a diagram detailing this demo setup in our web pages. So for more information please refer to http://www.join.uni-muenster.de/JOIN/ipv6/texte-englisch/budapest.html Greetings from Budapest, Guido ------------------------------------------------------------------------------ JOIN -- Join Open InterNetworks Guido Wessendorf An IP Version 6 Project of DFN Westfaelische Wilhelms-Universitaet Muenster Project Team Email: Universitaetsrechenzentrum join(a)uni-muenster.de Einsteinstrasse 60 http://www.join.uni-muenster.de D-48149 Muenster / Germany Phone: ++49 251 83 8459, Fax: ++49 251 83 2678, Email: wessend(a)uni-muenster.de ------------------------------------------------------------------------------

2 1

Re: IPv6 demo at JENC7, Budapest
by Paul Christ 15 May '96

15 May '96

Definitely congratulations: Paul Christ Allmandring 30 Communication Systems & D 70550 Stuttgart BelWue Development tel ++49 711 13 19 105 Computing Center 'RUS' fax ++49 711 678 7626 University of Stuttgart christ(a)rus.uni-stuttgart.d400.de On May 15, 4:51pm, JOIN Project Team wrote: > Subject: IPv6 demo at JENC7, Budapest > > Hello, > > I would like to inform you about our IP version 6 demonstration at the > JENC7 (Joint European Networking Conference) May 13-16 in Budapest, > Hungary: > > We have setup an IPv6 test network in Budapest connected to the Danish > research network DENet and to our IPv6 lab at the University of Muenster > in Germany. For the demo we use routers from the Danish company Telebit > Communications A/S and Suns running IPv6 for Solaris 2.5 (release 4.0). > > In Budapest we connected two Telebit routers via a 34 mbps ATM link > running IPv6 over ATM and exchanging routing information with IDRPv6. One > router in Budapest is connected to the IPv6 networks in Germany and > Denmark using static configured IPv6 tunneling (over IPv4 internet) and > exchanging routing information also using IDRPv6. > > We use both IPv4 compatible IPv6 addresses and full IPv6 addresses > according to RFC1897. > > So with this setup we provide full native IPv6 connectivity using the > RFC1897 test address space to the applications included in the Sun > software... > > We have included a diagram detailing this demo setup in our web > pages. So for more information please refer to > > http://www.join.uni-muenster.de/JOIN/ipv6/texte-englisch/budapest.html > > Greetings from Budapest, > Guido > > > ------------------------------------------------------------------------------ > JOIN -- Join Open InterNetworks Guido Wessendorf > An IP Version 6 Project of DFN Westfaelische Wilhelms-Universitaet Muenster > Project Team Email: Universitaetsrechenzentrum > join(a)uni-muenster.de Einsteinstrasse 60 > http://www.join.uni-muenster.de D-48149 Muenster / Germany > > Phone: ++49 251 83 8459, Fax: ++49 251 83 2678, Email: wessend(a)uni-muenster.de > ------------------------------------------------------------------------------ > >-- End of excerpt from JOIN Project Team

1 0

Re: agenda ?
by jrau＠dfn.de 21 Apr '96

21 Apr '96

> > I have not seen the agenda for the IPv6 WG for the meeting next week? > I have lost something or it is not yet available ? > Although I haven't seen an agenda either I want to suggest a small report by Guido Loeffler (Uni Muenster) about the state of his project. > Francis.Dupont(a)inria.fr > Juergen Rauschenbach, DFN

1 0

agenda ?
by Francis Dupont 19 Apr '96

19 Apr '96

I have not seen the agenda for the IPv6 WG for the meeting next week? I have lost something or it is not yet available ? Francis.Dupont(a)inria.fr

2 1

Draft minutes RIPE 23 IPv6 wg meeting
by RIPE NCC Staff 19 Mar '96

19 Mar '96

Dear People, Please find enclosed the draft minutes of the IPv6 working-group meeting at RIPE 23. Apparantly due to a misunderstanding these have not been sent out to the list yet. Appologies for the delay in sending these out. Kind regards, Naomi de Bruyn RIPE NCC OD: CNRS / UREC Tx: Bernard Tuy Dt: 23.02.1996 NF: ~/RIPE/Meetgs/IPv6wg.mn St: * DRAFT * IPv6 working group RIPE meeting minutes DRAFT RIPE meeting 23rd Amsterdam, January 30th Chair: Francis Dupont Scribe: Bernard Tuy 1. List of participants Peter Galbavy Demon Internet Ltd. Giles Todd Demon Internet Ltd. Nick Shield UKERNA/JANET Patrick Agren France Telecom Network Service paag(a)transpac.net Nick Reid Demon Internet Ltd. GeertJan de Groot RIPE NCC geertj(a)ripe.net Pulak Rakshit Cable online Graca Carvalho FCCN/RCCN Jan Hrdonka EUnet CZ Francis Dupont INRIA Dave Morton ECRC Hans Axen France Telecom Network Service haax(a)transpac.net Mark Cawley PostGEM cawleym(a)postgem.infonet.c Bill Cessna IBM Global Network wcessna @ vnet.ibm.com Ivan Communod FTNSNL ivan.communod(a)ftnsnl.atla Sabine Dolderer DENIC Sabine.Dolderer(a)nic.de Oliver Doll EUnet Deutschland GmbH od(a)Germany.EU.net Alfons Friedl SERVICOM afriedl(a)servicom.es Willi Huber SWITCH huber(a)switch.ch Christophe Huygens Katholieke Universiteit Leuven Christophe.Huygens@kulnet Avgust Jauk ARNES jauk(a)arnes.si Johannes 5 Joemann Object Factory GmbH joemann(a)object-factory.co Bettina Kauth DFN-NOC kauth(a)rus.uni-stuttgart.d Dusan Keprta EuroTel Bratislava Ltd. keprta(a)eurotel.sk Rushdul Mannan Xara Networks Ltd rm(a)xara.net Aidan Mcdonald RTC Carlow mcdonald(a)rtc-carlow.ie Pavel Mikus EuroTel Bratislava Ltd. mikus(a)eurotel.sk Vaclav Novak CESNET novakv(a)aci.cvut.cz Patrick O'Farrell PostGEM ofarrellp(a)postgem.infonet Serhat Oren IBM Global Network Europe Serhat_Oren(a)nl.ibm.com= Mariusz Ostrowski NASK mariusz(a)nask.pl Marc Pichon TRANSPAC pichon(a)rain.fr Juergen Rauschenbach DFN jrau(a)dfn.de Paul Rolland Oleane rol(a)oleane.net Miguel Sanz RedIRIS miguel.sanz(a)rediris.es Ivan Sedinic HPT - Croatian Post and Teleco ivan.sedinic(a)tel.hr Frank Slyne Telecom Eireann fslyne(a)internet.telecom.i Bernard Tuy CNRS / UREC Bernard.Tuy(a)urec.fr Pavel Vachek CESNET tkpv(a)earn.cvut.cz Tibor Weis SANET - Slovakia tibor(a)tuzvo.sk 2. Agenda (drafted during the meeting) . Status of IPv6 standards . Tools already available and implementation . what about experiments running today ? . who has (or plan to have) a testbed ? . AOB 3. Status of IPv6 standards 3.1 RFC (PS): . RFC 1883 IPv6 specifications . RFC 1884 Addressing architecture . RFC 1885 ICMPv6 specifications . RFC 1886 DNS extensions for IPv6 . RFC 1887 IPv6 Address allocation . RFC 1897 Test address allocation About Security in IPv6 (and IPv4 as well) one can refer to : . RFC 1825 Security architecture . RFC 1826 Authentication header . RFC 1827 Encapsulating security payload (ESP) . RFC 1828 MD5 authentication . RFC 1829 ESP DES-CBC transform . RFC 1851 ESP triple DES transform . RFC 1852 SHA authentication 3.2 Internet drafts (some of them...) : . transition mechanisms (draft-ietf-ngtrans-trans-mech-02.txt) . neighbor discovery (draft-ietf-ipngwg-discovery-04.txt) . dynamic host configuration (draft-ietf-dhc-dhcpv6-o3.txt) . IPv6 Stateless Address Autoconfiguration (draft-ietf-addrconf-ipv6-auto-07.txt) . IPv6 over Ethernet Networks (draft-ietf-ipngwg-ethernet-ntwrks-01.txt ) . IPv6 Packets over FDDI Networks (draft-ietf-ipngwg-fddi-ntwrks-01.txt ) . IPv6 over token ring (draft-ietf-ipng-token-ring-01.txt) . IP Version 6 over PPP (draft-ietf-ipngwg-pppext-ipv6cp-00.txt) . IPv6 Program Interfaces for BSD Systems (draft-ietf-ipngwg-bsd-api-03.txt) !attention! : a new API version is coming up. About IPv6 and ATM relationship, one can refer to the following references: . A Framework for IPv6 over ATM (neighbor discovery) (draft-schulter-ipv6atm-framework-00.txt) . IPv6 and neighbour discovery over ATM (draft-ietf-ipatm-ipv6nd-00.txt ) . Support for Multicast over UNI 3.0/3.1 based ATM networks (MARS) (draft-ietf-ipatm-ipmc-10.txt) . NBMA next hop resolution protocol (NHRP) (draft-ietf-rolc-nhrp-07.txt) ... For more information : http://playground.sun.com/pub/ipng/html/ipng-main.html (1) to participate the current IETF discussions, subscribe to ipng(a)sunroof.eng.sun.com 4. Tools and implementations 4.1 Tools already available: . tcpdump | > decode IPv6 packets . snoop (Solaris) | . BIND patches to support AAAA RR's 4.2 Implementations running: For complete information refer to URL (1) above. 4.2.1 Implementations for hosts with source code available : . INRIA (F. Dupont) NetBSD + FreeBSD available from ftp.inria.fr/network/ipv6 . NRL (R. Atkinson) 4.4 BSD Lite + BSD OS available from ftp.ripe.net 4.2.2 Implementations for hosts with binary code : . Solaris 2.5 version 3 . Digital / Unix version 3.2c . many others are available yet but less information is known about their functionalities : Helwett Packard / UX (SICS, Sweden) BULL (France) FTP Software ... 4.2.3 Implementations for routers . Bay Networks . Cisco Systems . Penril . Telebit (Denmark) ... 5. Testbeds (running or planned): . University of New Hampshire: interoperability experiments see Connectathon meeting (Feb. 5th to 9th) . Grenoble and Rocquencourt (France) interoperability FreeBSD / NetBSD / Solaris implementation tests of INRIA source code tunneling over IPv4 WAN (Renater) . University of Muenster (Germany) DFN and UNI-C tests with 3 Telebit routers . MITRE (= US ISP) 6. AOB: . 2 suggestions came from the audience, to have - the same Agenda at the Berlin RIPE meeting - one hour tutorial on a major IPv6 protocol (ND, ...) and on transition mechanisms at the same meeting. . status of the IPv6 working group: a consensus has been reached at this stage of knowledge of most of the attendees, to focus on what's going on about IPv6 standardization process and what is already running. On a later step, we'll consider to move to a more technical group where experiences of participants can be shared. ____ EoF.

1 0

FYI: outcome of UNH's test
by Geert Jan de Groot 15 Feb '96

15 Feb '96

As requested by the IPv6 WG, some highlights of the UNH testathon. ------- Forwarded Message Date: Wed, 14 Feb 1996 13:14:53 -0500 From: Bill.Lenharth(a)unh.edu (William Lenharth) To: ipv6imp(a)munnari.OZ.AU Subject: [IPv6Imp] IPv6 testing at UNH IPv6 Group Test Period at UNH A group test period was held at UNH9s Research Computing Center9s Interoperabil ity laboratory during the week of Feb 5-9, 1996. In attendance were equipment and personnel from DEC, SUN, HP, Bay Networks, Ipsilon, INRIA (France), The WID E project (Japan), Hitachi, FTP Software, and Mentat, over 20 pieces of equipme nt and 32 people. Steve Deering was also in attendance as an observer, repres enting the IETF. A network was constructed by UNH consisting of three links connected with a sep arate router and the remaining connection on each router tied to a backbone. A router running only IPv4 was also connected to the entire network and then co nnected to the internet via UNH9s network. This router offered reliable commun ications during IPv6 router testing. Testing was conducted on each link and then across link through the IPv6 router s. UNH supplied a testing and monitoring system based on the RFC9s covering th e Base IPv6 standard, Addressing architecture, Neighbor discovery process inclu ding Duplicate address detection, Router advertisements - solicitations, and pa cket fragmentation and reassembly. As expected, problems with all implementations were located. The breadth of th e implementations were also varied, and therefore all tests were not run on all systems. UNH has been testing implementations of participating vendors since the fall Interop show held in Atlanta and there has been a marked improvement i n all aspects of those particular implementations. We welcome any comments or questions (whl(a)unh.edu) Those wishing to see a slide show taken at the test pe riod may do so by connecting to our web site, www.iol.unh.edu - under IP consor tium - 3Slide show of group test period2. Current plans call for another group test period in June of this year at UNH be fore the IETF meeting to be held in Montreal, Canada. UNH has also been contac ted by Interop and they have encouraged us to once again man a booth displaying emerging communications technologies. Current plans regarding the involvement of the IPv6 Consortium group are incomplete at this time. If there are any com panies interested in participating in an IPv6 test network at InterOp please co ntact us at whl(a)unh.edu. I will submit further information on IPv6 testing pl ans on this list as they are solidified ------- End of Forwarded Message

1 0