February 2003 - ipv6-wg - mailman.ripe.net

[ipv6-wg@ripe.net] Reverse delegation for 6bone address space in ip6.arpa
by Andrei Robachevsky 04 Apr '03

04 Apr '03

Dear Colleagues, In accordance with RFC 3152, the administration of the name space within ip6.arpa has been delegated to the RIRs. The 3FFE::/16 address space has not yet been allocated to the RIRs by the IANA. It is the intention that the RIRs administer this space. The community has expressed a need for 3FFE reverse space to be in the ip6.arpa domain. The RIR CEOs sent a message to the IAB requesting a waiver regarding the RFC 3152 requirement and received a positive response. The RIRs are prepared to administer e.f.f.3.ip6.arpa domain in the manner as described below. We plan to implement it in the next few weeks and deliver the solution soon after the RIPE 44 Meeting in January. Regards, Andrei Robachevsky CTO, RIPE NCC Support for reverse delegation for 6bone address space in ip6.arpa DNS tree --------------------------------------------------------------------------- Phase I. Before a final decision is made on future management of the 3FFE address space The delegation for e.f.f.3.ip6.arpa is made by IANA to one of the RIRs. Zone information for this space is produced by copying the existing delegations in the e.f.f.3.ip6.int zone. Additional check is done to ensure that the servers corresponding to the NS RR are also authoritative in .arpa space. Zone information is updated whenever changes are detected in the e.f.f.3.ip6.int zone. This approach has a couple of advantages. It keeps the RIRs out of the 6bone registration process until a final decision is made on future management of the 3FFE address space. It also implies no procedural changes from a user's perspective since changes are made in only one place, while at the same time it moves responsibility for maintaining the e.f.f.3.ip6.arpa zone to the RIRs. This then prepares for a smoother transition to Phase II. The main constraint of this approach is that it forces registrants to use the same name servers for .arpa as for .int. Phase II. Registration of 3FFE space is transferred to the RIRs A shared zone management process will be implemented similar to that currently implemented by the RIRs for the legacy v4 space (ERX project, http://www.ripe.net/db/erx/) That is, holders of 6bone address space will be served for reverse delegation by the respective RIR in their region, and the generation of the e.f.f.3.ip6.arpa zone can be entirely automated using zone merging.

2 2

[ipv6-wg@ripe.net] IXP networks routing
by Nicolas DEFFAYET 14 Mar '03

14 Mar '03

Hello, We hesitate to allow IXP's /48 in our routing table. http://www.ripe.net/ripe/docs/ipv6-policy-ixp.html => "Networks assigned under this policy may not be globally routable." What's the best practice ? Thanks Best Regards, -- Nicolas DEFFAYET, NDSoftware NDSoftware NOC: http://noc.ndsoftwarenet.com/ FNIX6 (French National Internet Exchange IPv6): http://www.fnix6.net/ EuroNOG: http://www.euronog.org/

11 15

[ipv6-wg@ripe.net] Re: Reverse delegation for 6bone address space in ip6.arpa
by Axel Pawlik 20 Feb '03

20 Feb '03

Petr, all, over the last months, the RIRs have developed a reasonably pragmatic procedure to basically mirror the reverse delegation entries under ip6.int into ip6.arpa. Today, we have a working prototype implementing this approach. Unfortunately, our proposal has not been received favourably by the current administrator of the 6bone reverse delegations. To satisfy the needs of our members, however, we are now discussing another way to provide this functionality in a different way, building on the experiences we have made during the Early Registrations Transfer (ERX) Project. We will coordinate this closely with the other RIRs during next week's APNIC meeting; we are obviously also keeping an eye on the 6bone developements as regards the registry transfer and phaseout proposals. Expect a progress report after that. regards, Axel

3 3

[ipv6-wg@ripe.net] network's architecture under IPv6
by BEGIN, Thomas 20 Feb '03

20 Feb '03

Hello to all, I am wondering on IPv6 impacts over a company network's architecture. I mean, a big IPv4 network has to be divided in several VLANs in order to lighten the available bandwidth (sometimes for security reasons but it is not my interest in this case). And this because broadcast messages are received and examined by all network adapter. Thus comes my question: As there is no more broadcast messages but only multicast messages in IPv6, is there still a need to divide a big network in smaller networks (VLANs) ? Thanks Thomas BEGIN

2 1

[ipv6-wg@ripe.net] network's architecture under IPv6
by BEGIN, Thomas 20 Feb '03

20 Feb '03

Hello to all, I am wondering on IPv6 impacts over a company network's architecture. I mean, a big IPv4 network has to be divided in several VLANs in order to lighten the available bandwidth (sometimes for security reasons but it is not my interest in this case). And this because broadcast messages are received and examined by all network adapter. Thus comes my question: As there is no more broadcast messages but only multicast messages in IPv6, is there still a need to divide a big network in smaller networks (VLANs) ? Thanks Thomas BEGIN

1 0

[ipv6-wg@ripe.net] Second IPv6 deployment survey
by leo vegoda 20 Feb '03

20 Feb '03

Dear Colleagues, At the IPv6 WG session at RIPE 44 last month, the RIPE NCC was requested to conduct a second survey on IPv6 deployment. Information on the first IPv6 deployment survey conducted by the RIPE NCC is available at: <http://www.ripe.net/ipv6/ipv6-survey-summary.html> <http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe 42-ipv6-survey/index.html> In the last survey we contacted LIRs that had received IPv6 allocations. To help develop the structure of the second survey, we would like community input on the following issues: 1. Should the survey be restricted to RIPE NCC members? 2. Should the survey be restricted to those holding IPv6 address space? 3. If the answer to 2 is "yes", should those networks have had the address space for any particular length of time? We would also appreciate comments on issues that are important to the IPv6 community with regards to IPv6 deployment. We look forward to your input. Kind regards, -- leo vegoda RIPE NCC Registration Services

2 1

[ipv6-wg@ripe.net] New IPv6 block allocated to RIPE NCC
by leo vegoda 17 Feb '03

17 Feb '03

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:1400::/23 from the IANA in February 2003. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Kind regards, -- leo vegoda RIPE NCC Registration Services

2 1

[ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Andrius Kasparavicius 14 Feb '03

14 Feb '03

Hello, what I should think about when I allocate IPv6? :-) Just like IPv4 subnets for needed IP devices, the same but multipled(how much?) for future hierarchy, divide all I have for all who need(best hierarchy). Divide geographically, by organisations, people population for best hierarchy all v6? I look ahead, hierarchy.. a lot of IPv6. Hmm.. And at the end, would I be bad if I will use /127 for point-to-point(tunnels). respectfully, Andrius

7 29

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 14 Feb '03

14 Feb '03

Gert, >> Michel Py wrote: >> available for that. What Gert wants is a large number of >> bits to make the subnet number look good, in the *subnet* >> bits, > Gert Doering wrote: > Call it "look good", but at least you understand the goal. > I appreciate that. Don't get me wrong: the goal (like any naming convention) is good (although operational experience suggests that in this very case it will be useless after a few years). This is not the point. The point is that you think that you can use the IID bits for routing purposes. This discussion has come five times on the table in the last 10 years and has always ended in the hole. In a nutshell, what you want is to declare that the IID bits could have a mixed use, either as IID bits or as subnet bits. Sharing the IID bits for routing purposes is not a good idea, and we just don't have enough bits to do what you want otherwise. > At least four people have voiced here that they are doing this, > and I'm pretty sure that many more networks are doing non-/64s > on point-to-point links for similar or other reasons) As Randy and I said before, the ipv6 WG would be the place to discuss addressing architecture issues. I will clue you though that what some call the "old guard" includes lots of very knowledgeable people with CONSIDERABLE operational experience, including a number of people that have tried what you suggest before with other protocols. Large address spaces such as IPv6 are nothing new to some of us. More than a decade ago, I was dealing with a lot of Novell/IPX networks. The IPX address is 80 bits, 48 IID bits and 32 subnet bits (Hex notation same as IPv6). We did see a lot of funny subnets numbers such as "BABE4B0B" and a few other more explicit ones that I can't really mention here. They were contests to name subnets in the good old IPX days. Anyway, at the time these 32 subnet bits were more than enough to do what you are suggesting for IPv6, some people including myself actually tried, and after reorganizing and merging networks it becomes meaningless. In short: Nice idea, bit a) it does not work in the long run, we tried it before and b) even if it did the benefits that it brings are not worth running the IID bits in mixed mode anyway. Michel.

2 1

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 14 Feb '03

14 Feb '03

Stephane, > Stephane Bortzmeyer wrote: > Clearly, it is not so simple. While you cannot encode > *everything* even in 128 bits (billing status), it is > better when you can encode at least a few things. Yes, it is better when you *can*. > Otherwise, "serious" operators would not name their > routers with sensible names like > P12-0.NYKCR2.New-york.opentransit.net This takes 296 bits, btw. It is done because it *can* be done because it's a name, and that's exactly what names have been designed for. Not IP addresses. This is not the issue anyway: We are not talking about configuring the MAC address with a structure that is meaningful; this can be done already and there are 62 bits available for that. What Gert wants is a large number of bits to make the subnet number look good, in the *subnet* bits, totally ignoring conservation. Where does this come from? Nobody does that except him, nobody does it in v4, it has never been part of v6. We can't allow end-sites to do that kind of thing, they would all need at least 48 subnet bits as well. Michel.

3 2

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 14 Feb '03

14 Feb '03

Christian, >> Michel Py: >> No we *don't*. The IETF standards are decided by consensus, >> and the IID bits are not yours to play with for routing >> purposes. There are other legitimate uses for these 64 bits, >> such as embedding some crypto in theIID or privacy extensions. > Christian Schild wrote: > please, we are talking about point-to-point links here. Michel, > what you say (and what is written in the draft) is perfectly > reasonable, when thinking about a 'real' link. I think a PtP > link is some kind of an exception. There is nothing 'inside' a > PtP link, just a source and a destination. The only reason to > use a subnet for such a link, is a better management. So why > should a piece of software or a software developer rely on the > fact, that there is a /64 on a PtP link. Again, it is correct > to expect this from a usual link, but not from a PtP link. I don't agree. Look at a supposedly private cross-country frame-relay link. It _appears_ to be a point-to-point link. From the router's standpoint, you don't know if there's one frame-relay switch between you and the other end, or twenty; you don't know if traffic stays within the frame-relay cloud or is tunneled into IP or carried over ATM. You don't even know how many carriers are involved. It's not a lot more secure than going over the public internet and if you are security conscious you will encrypt end-to-end traffic and use the BGP MD5 option. These ptp links are the exact target of work being done that include things such as embedding the crypto key or part of it in the MAC address. Michel.

2 1

[ipv6-wg@ripe.net] Browsers
by Priyaupnp＠netscape.net 13 Feb '03

13 Feb '03

hi all, pls let me know what are the ipv6 enabled browsers which can be installed in linux. Thanks in advance Pria __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

6 5

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 13 Feb '03

13 Feb '03

> Andrius Kasparavicius wrote: > And at the end, would I be bad if I will use /127 > for point-to-point(tunnels). VERY bad. Not only there are known issues with doing this, but it violates both RFC2373 and its replacement draft-ietf-ipngwg-addr-arch-v3-11.txt. Not respecting IETF _standards_ is not a good idea in any case and at some point people that think they are gods and can have their own standard will have to renumber their entire network. Michel.

4 3

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 13 Feb '03

13 Feb '03

> Daniel Karrenberg wrote: > I'll admit that I do not follow the details of this > discussion but I want to offer a bit of general advice > based on considerable operational experience: > Overloading layer three addresses with clever numbering > schemes never works in the long run. Yep. After a while it becomes more misleading than anything else. Michel.

1 0

Re: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Christian Schild (JOIN Project Team) 13 Feb '03

13 Feb '03

Am Mittwoch, 12. Februar 2003 23:47 schrieb Michel Py: > No we *don't*. The IETF standards are decided by consensus, and the IID > bits are not yours to play with for routing purposes. There are other > legitimate uses for these 64 bits, such as embedding some crypto in the > IID or privacy extensions. Please, we are talking about point-to-point links here. Michel, what you say (and what is written in the draft) is perfectly reasonable, when thinking about a 'real' link. I think a PtP link is some kind of an exception. There is nothing 'inside' a PtP link, just a source and a destination. The only reason to use a subnet for such a link, is a better management. So why should a piece of software or a software developer rely on the fact, that there is a /64 on a PtP link. Again, it is correct to expect this from a usual link, but not from a PtP link. Maybe the ADDRARCH draft is flawed and it should clearly exclude PtP links when requiring a /64. So long, Christian

1 0

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 13 Feb '03

13 Feb '03

> Gert Doering wrote: > (And because it makes maintenance and setup much easier, We call that troubleshooting with the seeds of the pants, which exactly what serious operators don't do. > as I don't have to go to some place to find a "get me a free subnet", > I just can have the machine assign it ad-hoc, just by telling it the > router name/id and the interface name. This a disaster waiting to happen. A subnet is documented in a subnet database, not in the router's config; the first thing to do *before* configuring a subnet is to create the db record and populate it. Not maintaining proper documentation is cause for termination in lots of shops. Engineering with the seeds of the pants again. > We *have* the address space, No we *don't*. The IETF standards are decided by consensus, and the IID bits are not yours to play with for routing purposes. There are other legitimate uses for these 64 bits, such as embedding some crypto in the IID or privacy extensions. > Of course it is very much possible with 128 bits. People *do* this, > so it's possible, isn't it? I will laugh when you have to renumber because suddenly a new security protocol that uses 56 of the 64 IID bits is required. > The thing that is not possible is to accommodate for that inside > the very narrow-minded "one size fits all" mind-set that made the > rule that one should use a /64 on a point-to-point link. This is called "standardization". That's why you can plug a refrigerator, a microwave oven and a cell phone charger in the same power outlet. The microwave takes 10,000 times more power than the cell phone charger, and indeed the wiring for a power outlet that could accommodate only cell phone chargers would be a lot lighter. Do you want 20 types of power plugs in your data center? > There is no reason (except "one size fits all") *for* that rule > - or at least nobody in this discussion named one - but many good > reasons *against* it. This has been debated before and the IETF has decided otherwise. People that maintain correct network documentation do not need nor desire fancy allocation schemes. Often, these same people that maintain correct documentation respect standards, btw. Michel.

4 3

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 13 Feb '03

13 Feb '03

Gert, > Gert Doering wrote: > I just want to point out that this discussion is *not* about > tunnels only. It's about generic addressing plans for point > to-point links, and the failure of /64s to address the needs > of *ops* types. This discussion does not belong here. The RIRs responsibilities are what's on the right of /64, not what's on the left. > Unfortunately, ISP networks usually consist of *many* point-to > point links, and all of them want to be addressed in a structured > and time-saving (!) way. Which means "use some of the available > bits to do structure" - and if you use up a /64 per link, you need > those bits further up, and those are just not there in the current > policy frame work. Oh really? Mmmm, how many of the 4 billion /64s you have been allocated do you need? By my account, a network with 60k subnets including 1/3rd of ptp and loopbacks fits in a /44, including loss to internal aggregation. > (If the RIR->LIR allocation/assignment framework is changed to > hand a /16 to every LIR, such a scheme might not be a problem. > In the current scheme, it is). If you can demonstrate that you need more than a /32, you might get it. Show us the numbers. Michel.

5 4

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 12 Feb '03

12 Feb '03

Gert, > Gert Doering wrote: > Hummm? You're a bit confused about left and right? Doh! > But this is what IPv6 is all about, isn't it? Give people a big > enough address space so that they can do things the *easy* way, > instead of the conservative way. Allocate sparsely, and make use > of the address space. Yes, but to a reasonable extent. Following your logic, you will soon need 16 more bits to accommodate 32-bit ASNs, then it would also be nice to have some bits to say if the customer's router a Cisco or a Juniper or Linux, some other bits so match the link type, and speed, and so on. It never ends, because each network has specific needs. I hear what you say; it would be elegant just by looking at the prefix to be able to tell something about it. In the end though, it does not replace network documentation which is paramount for operations. When I troubleshoot a route, I will lookup in the database anyway to see where it goes, over what kind of link, etc. There's stuff you can't put in the address, such as billing. Example: the customer calls the NOC whining being down. He's down because he has not paid. Yes, you could put in the interface description that it was shutdown by Joe because of billing issues, but I'd rather have the telco CktID there. If your NOC tech does a no shut without looking up the database and customer info, you're wasting money because someone else will waste more time shutting it down another time. This is all about good operational practices: if your documentation and change management are good, you don't need that kind of trick. You want to know what a prefix is about? Lookup the database, it will tell you what you need and possibly things you might not have thought about, such as billing. > My numbering plan requires AS number, router ID and link > number in the network part for each point-to-point link. This is what is flawed, IMHO. You basically say that you want 48 bits out of the address space just to have subnet numbers that look neat. If the IPv6 address was 256 bits that would have been possible but not with 128 bits. Michel.

2 1

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 12 Feb '03

12 Feb '03

Robert, >> Michel Py wrote: >> +-----+---------+---------+-------+--------------+ >> | 8 | 16 | 16 | 8 | 16 | >> | | hostid | | index | routernumber | >> +-----+---------+---------+-------+--------------+ >> 02 ca : fe FF : FE 77 : beef > Robert Kiessling wrote: > I'm talking about network address derived from router number > and some local interface index. This is not possible in the > 16 bits available in the assignment. I don't understand; there are 40 bits in the example? (and I could have squeezed 6 more). > cisco3640(config-if)#mac-address ca.fe77.beef > Changing the MAC address to get an easily usable IP address > seems quite perverse to me. Indeed it is, but this was the long way to demonstrate how it is derived. And is besides the point, as we were talking about tunnels and they don't have a MAC address of their own, so you can go ahead and directly configure an EIU-64 or modified-EUI-64 IPv6 address directly as show in the short way. Michel.

2 1

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 12 Feb '03

12 Feb '03

Sam, > Sam Wilson wrote: > It's an odd feature of that RFC that it's published as > Informational rather then Proposed Standard, Which RFC are you referring to? 2373 is in the standards track and so is draft-ietf-ipngwg-addr-arch-v3-11.txt which is going to obsolete 2373 soon. >> [RFC2373] >> Network Working Group R. Hinden >> Request for Comments: 2373 Nokia >> Obsoletes: 1884 S. Deering >> Category: Standards Track Cisco Systems > and the only reference to the RFC 2119 terms "MUST", "MUST NOT" etc. > is in the Introduction. It specifically does not say: > "Interface IDs are REQUIRED to be 64 bits long and to be > constructed in IEEE EUI-64 format [EUI64]." > Perhaps someone who is further into the the IETF process can say > whether this was an oversight or if the latitude was intended. I can't speak for the authors in terms of intent, but the fact of the matter is that if it said "REQUIRED" there would be no compliant implementation today, which would forbid the standards track. This very point has actually been appealed recently, so regardless of the intent the latitude is necessary as of today. This an egg-and-chicken problem: there are a lot of legacy tunnels that use /127, and software developers don't want to enforce the /64 boundary because it would force legacy networks to renumber, which can't happen overnight so the likely result is that almost no one would use the updated software which is no good for a protocol under development such as IPv6. This is largely a user education problem, because the old reflexes of using a /30 or a /31 that are justified in v4 are not required anymore for v6. Michel.

1 0

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 12 Feb '03

12 Feb '03

> Do the ops types include people like me who worry that every > time a NIC has to be replaced it's going to require changes > to DNS, ACLs and anything else that's keyed on IP address? Mmm, I don't know. I'm the kind of ops type that also reads RFCs and understand the importance of respecting standards. From an operational standpoint, it pays off in the long run. I would never configure a server or router with an IPv6 address that includes some part of the BIA, but I try to respect standards too, and even the current standard could be respected although its clumsiness definitely makes modified EUI-64 desirable. Michel.

1 0

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 12 Feb '03

12 Feb '03

Robert, > There are a number of advantages of non-/64 for p2p. For example, > you can have an easy address allocation scheme like ...: > <routernumber>:<index>:<host id>" which does not require any > bookkeeping. That's not possible with /64 addresses. You are completely mistaken. Using your own example: Hostid = 0xcafe Index = 0x77 Routernumber = 0xbeef I'll even go over an EUI-64/RFC2373 example although it's going to be obsolete real soon. +-----+---------+---------+-------+--------------+ | 8 | 16 | 16 | 8 | 16 | | | hostid | | index | routernumber | +-----+---------+---------+-------+--------------+ 02 ca : fe FF : FE 77 : beef The long way: ------------- cisco3640#conf t cisco3640(config)#inte e0/0 cisco3640(config-if)#mac-address ca.fe77.beef cisco3640(config-if)#ipv6 address 2001:db8::/64 eui-64 cisco3640(config-if)#end cisco3640#sh ipv6 inte e0/0 Global unicast address(es): 2001:DB8::2CA:FEFF:FE77:BEEF, subnet is 2001:DB8::/64 ^^ ^^ ^^ ^^^^ \\|| || |||| CAFE 77 BEEF The short way: cisco3640#conf t cisco3640(config)#inte e0/0 cisco3640(config-if)#ipv6 address 2001:db8::02CA:FEff:fe77:BEEF/64 This is compliant with EUI-64 and RFC 2373. As I said before, we're talking about straight EUI-64 here and this is soon to be obsoleted. The replacement for RFC2373 (draft-ietf-ipngwg-addr-arch-v3-11.txt) uses _modified_ EUI-64, and you can do almost whatever you want, such as: ipv6 address 2001:db8::02CA:FE00:0077:BEEF/64 ipv6 address 2001:db8::02:CAFE:77:BEEF/64 ipv6 address 2001:db8::1/64 All of which are compliant modified EUI-64 addresses. > The standard also requires EUI-64 addresses which is clearly > not desirable for a number of application. For example, it would > be very silly to require a change all your peering sessions just > because you change your NIC. There is no relation. You can construct an EUI-64 or a modified EUI-64 address without using the BIA, what's your problem here? Michel.

2 1

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 12 Feb '03

12 Feb '03

> Jeroen Massar > Thus 2001:db8::1 is a 'modified' EUI-64 and thus can be > assigned. You are just lying a bit that the local scope > id is not available and thus you are making it up, but > you do correctly set it as per RFC. Easy to fix, make it 2001:db8:2::1 Michel.

1 0

[ipv6-wg@ripe.net] urls with ipv6 ip.
by Priyaupnp＠netscape.net 06 Feb '03

06 Feb '03

hi all, I couldn't load a loacal page from my linux system with IPv6 link local IP,(The browser used was netscape7). When the site local ip is added to the system, could load the page using that ip. Is it possible to load a page with link local ip using netscape or any other browser. Thanks in advance. Regards Pria __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

3 2

[ipv6-wg@ripe.net] ANNOUNCEMENT: IPv6 support for RIPE NCC TTM Service
by Henk Uijterwaal (RIPE-NCC) 03 Feb '03

03 Feb '03

Dear All, (Apologies for any duplicate mails). The RIPE NCC is pleased to announce full IPv6 support for its test-boxes and Test Traffic Measurement Service (TTM). This new version can do all the measurements that the previous version could do on IPv4 networks, but now on IPv6. Measurements can be done on IPv4 and IPv6 networks in parallel. Most of the porting work has been done by Florian Frotzler, an CS student doing an Internship at the RIPE NCC. It is described in more detail in an internal report available at: http://www.ripe.net/ttm/Documents/Various/florian_xmas.pdf as well as in the slides of his presentation at RIPE44 last week: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-tt-i… IPv6 support will be included on all test-boxes ordered after 1/2/2003. To order a test-box, please go to: http://www.ripe.net/ttm/Host_testbox/host_testbox.html If you are already hosting a test-box and want to upgrade to the IPv6 enabled version, then please find instructions for upgrading at the bottom of this mail. If anything is unclear, please contact us at ttm(a)ripe.net. More about the TTM service can be found at: http://www.ripe.net/ttm Kind regards, Henk Uijterwaal Instructions for upgrading test-boxes ===================================== If you already own a test-box and want to upgrade to the IPv6-capable version of the software, then this is the procedure: 1. Determine the version of your test-box. This can be series A, B, C or D. Series D boxes are 1u high and manufactured by Dell. Series C boxes are all boxes delivered after 1/1/2001. A or B are boxes delivered before 1/1/2001. 2. Your box is series A or B: 1. In this case, a hardware upgrade to a series D box will be necessary. The (usually 3-5 years) old hardware does not support v6. 2. Series D boxes cost 2,500 euro, however, if you return your old box, you will get a 500 euro discount. 3. Send an email with a v6 address to tt-ops(a)ripe.net 4. A new box will be configured and shipped. 5. Schedule a time to unplug the old box and plug in the new box with our operators. 3. Your box is series C or D: 1. Send an IPv6 address to tt-ops(a)ripe.net 2. Our operators will schedule a time for the upgrade 3. You will have to download a boot floppy from our ftp site. 4. At the time of the upgrade, boot with the floppy. Note that we will only do this upgrade if all outstanding invoices have been paid and the service contract for the existing box has been signed. ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(a)ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC)

1 0