January 2003 - lir-wg - mailman.ripe.net

80.x.x.x cannot resolve .zw addresses
by Chris Ransley 15 Jan '03

15 Jan '03

Hi guys, We are having an issue when trying to resolve Zimbabwe address eg: cfs.co.zw, zol.co.zw. I tried on two 80.x.x.x networks. 80.71.96.0 255.255.240.0 & 80.77.192.0 255.255.240.0 Can anyone help? Best Regards, Christian Ransley B.Sc. Web & Technical Services Manager Keyworld Ltd. UB42, Industrial Zone San Gwann SGN 09 Tel: (+356) 2540 2540 Fax: (+356) 2540 9999 Email: webmaster(a)keyworld.net Website: http://www.keyworld.net

2 1

IPv6 assignments to RIPE itself
by Robert Kiessling 15 Jan '03

15 Jan '03

Hello, RIPE uses addresses which are unassigned: > host -t aaaa ns.ripe.net. ns.ripe.net IPv6 address 2001:610:240:0:193::193 > whois 2001:610:240:0:193::193 inet6num: 2001:0610:0240::/42 netname: RIPE-NCC-IPv6 descr: RIPE NCC status: ALLOCATED-BY-LIR In my understanding, this is not an allowed usage sice RIPE must assign a /48 to themselves before the use the address space. However, I rose this issue with them, and they claim there is not need for this. Could someone please explain to me where my understanding of the allocation and assignment rules is flawed? Thank you, Robert

5 10

RE: [lir-wg] IPv6 assignments to RIPE itself
by matthew.ford＠bt.com 15 Jan '03

15 Jan '03

> -----Original Message----- > From: Alexander Gall [mailto:gall@switch.ch] > Sent: 15 January 2003 09:15 > To: Gert Doering > Cc: Stephane Bortzmeyer; Jeroen Massar; 'Wilfried Woeber, > UniVie/ACOnet'; lir-wg(a)ripe.net > Subject: Re: [lir-wg] IPv6 assignments to RIPE itself > > > [Probably opening a can of worms here...] Yuk, worms taste bad .... ;-) <snip> > I agree. The numerics in section 4 of RFC3177 assume that the top 45 > bits in 2000::/3 can be utilized with an H ratio of 0.25 (giving on > the order of 10^11 /48). IMHO, the problem with the current > allocation policy is that it is a lot more conservative than RFC3177 > suggests while still holding on to the /48-for-everybody rule. The > relatively small LIR allocations create a level of scarcity in the > number of /48's, which is enough to make people believe that giving a > student as much address space as her entire University is just crazy. > However, the whole point of RFC3177 was that this should be completely > irrelevant. It *is* completely irrelevant. Allocate /48s, exhaust existing RIR allocation, get more addresses from RIR. I don't see the problem. -- Mat.

6 11

Re: [lir-wg] IPv6 assignments to RIPE itself
by Wilfried Woeber, UniVie/ACOnet 15 Jan '03

15 Jan '03

>> Alexander Gall has summarized it pretty well - if we want to give out >> /48s freely, then the quite conservative RIR->LIR allocation policy >> currently in place *hurts*. > >Very true if you mean that you cannot build a reasonable hierarchy. Actually, this is the thing that makes the use of the /42 block out of SURFnet's sTLA to RIPE (Meeting et.al.), The NCC and the employees interesting: I do see it as people actually trying to _live_ and document that hierarchy - LIR => RIPE NCC (status: ALLOCATED-BY-LIR) => various assignments by the RIPE NCC. >> As for the argument "are universities ISPs"? Yes, at least over here, >> a fair number of them are providing IP connectivity to the student's >> hostels via leased line/ethernet, and to all other students via ISDN/Modem >> dialup. So for all address management purposes, they are ISPs. > >This is true in the Netherlands too. Same here. We even operate our own ADSL gear on-site for connecting hostels, students, etc. >Yes, I think those should be treated >as ISPs, probably getting a prefix (>> /48) from their NRN. That's something we are trying to get a feeling for at the moment. My approach for _now_ is to treat a University's (extended) LAN as one site (i.e. lives within 1 /48), and the hostels and remote customers' (students and faculty) networks as a site (/48 typically or /64 in special circumstances) each. As regards the address distribution procedures I still maintain that there is no technical or logical difference between a university's "customer" which happens to be staff or student as compared to a "regular" customer serviced by a "commercial" ISP. Also, the technology used to ship IPv6 packets should be irrelevant for this discussion, i.e. a native link or an IPv6 in IPv4 tunnel to such a network doesn't make a difference. > rvdp Btw, regarding the discussion of what a "site" is - my current interpretation here is that a "site" is the entity I am talking to with regard to network planning and address space management. And if that entity most probably uses more than a singel subnet, then I usually stick to the /48 recommendation. Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

Re: [lir-wg] IPv6 assignments to RIPE itself
by Wilfried Woeber, UniVie/ACOnet 15 Jan '03

15 Jan '03

Sorry, Gert, >> As Leo already explained: RIPE != RIPE NCC. I see the usefulness of >> a /48 that travels along with the RIPE meetings. As far as I know, >> this /48 always has the same upstream (the RIPE _NCC_ office) by >> means of a v6-in-v4 tunnel. > >And exactly this is the reason why I don't see the need for a second /48. I don't get your point here. What are you trying to salvage? 1x /48 out of SURFnet's sTLA or 1x /48 out of the /42 or ?? Wilfried.

2 1

RE: [lir-wg] should aut-num object for IPv4 & IPv6 be the same?
by adrian.pauling＠bt.com 15 Jan '03

15 Jan '03

we have 'inet6num' objects separate to 'inetnum' to distinguish IPv6 address assignments from IPv4. Is the question should different 'peering-set' 'route' objects etc reflect different peerings for IPv6 from IPv4 that an assigned AS can have? This scenario is real as I can easily give a current (enterprise LIR) example. Regards, Adrian F Pauling BT Ignite Solutions

2 1

Re: [lir-wg] IPv6 assignments to RIPE itself
by Wilfried Woeber, UniVie/ACOnet 15 Jan '03

15 Jan '03

>| > whois 2001:610:240:0:193::193 >| inet6num: 2001:0610:0240::/42 >| netname: RIPE-NCC-IPv6 >| descr: RIPE NCC >| status: ALLOCATED-BY-LIR I think there are 2 questions here that should be discussed, under the premises that SURFnet has set aside a /42 for the NCC from SURFnet's sTLA: a) what is the "correct" status: field for a block bigger than /48 I think in most cases (like /47, /46 for a big site) it should simply be ASSIGNED, even if it is as big as a /42. b) in a more general sense, to what level are we (LIR) and our sites/customers (/64, /48 or bigger) expected to document internal address management? For the moment, the only thing that looks funny _for me_ is the status: "ALLOCATED-BY-LIR". I read that as an indication that the NCC would make _assignments_ from that block, e.g. /64s and /48s - which I think _should_ be registered by the NCC or by SURFnet. Wilfried.

7 8

should aut-num object for IPv4 & IPv6 be the same?
by Andrius Kasparavicius 15 Jan '03

15 Jan '03

hello, IPv6 AS policy can differ from IPv4, should we ignore IPv6 then? Andrius

2 1

RE: [lir-wg] IPv6 assignments to RIPE itself
by Wilfried Woeber, UniVie/ACOnet 15 Jan '03

15 Jan '03

Hi Jeroen! >Only problem here is that in the non rwhois databases there is no >defacto 'referal' method. At least as far as I know of except for >a 'remarks:' field. If somebody can hint me where to find it I would >be pleased. Interesting line of thought! In fact there _is_ a referral mechanism - for domain lookups, but not for address lookups. Depending on what the result of this discussion is, we could investigate the merits of a referral mechanism for inet6nums, too. Nevertheless I'd strongly suggest to keep the (minimal) required documentation of resources in the central database, instead of going down the route of rwhois (or the like). Wilfried.

2 1

Re: [lir-wg] IPv6 assignments to RIPE itself
by Andrei Robachevsky 14 Jan '03

14 Jan '03

Dear Robert, colleagues, > Hello, > > RIPE uses addresses which are unassigned: > > > host -t aaaa ns.ripe.net. > ns.ripe.net IPv6 address 2001:610:240:0:193::193 > > > whois 2001:610:240:0:193::193 > inet6num: 2001:0610:0240::/42 > netname: RIPE-NCC-IPv6 > descr: RIPE NCC > status: ALLOCATED-BY-LIR > > In my understanding, this is not an allowed usage sice RIPE must > assign a /48 to themselves before the use the address space. > This is our fault that the assignments we made were used before they were registered as inet6num objects with "ASSIGNED" status. This has now been corrected. I would like to note that this space wasn't allocated by the RIPE NCC to the RIPE NCC itself, but rather by SURFnet to their customer - RIPE NCC operations department and then assigned to their customers - RIPE NCC's network, RIPE meeting network and home networks of the NCC's staff. I must also apologise to SURFnet as this might have affected their HD ratio. > However, I rose this issue with them, and they claim there is not need > for this. > > Could someone please explain to me where my understanding of the > allocation and assignment rules is flawed? > > Thank you, > > Robert > Regards, Andrei Robachevsky CTO, RIPE NCC

1 0