Re: [lir-wg] IPv6 assignments to RIPE itself
| > 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.
Wilfried Woeber, UniVie/ACOnet wrote:
| > 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.
IMHO the assignments for the /48's should be documented in a local (r)whois database. With at least a referal from the central whois. Anything bigger than one /48 should be documented in the central (whois.ripe.net) database. This should 'lighten' the load on the central whois as there are 2^(128-32-48=48) (a lot) of /48's to be registered in to the database. As for the reason why I think those /48's should be registered: When a spammer/abuser/* is using 1 IP out of the /48 it would be better to contact the onsite administrator then the upstream ISP. And especially as a /48 could hold a major corporation or a big university this is something that IMHO should be very useful. Ofcourse one shouldn't be forced to use the defacto whois software but could integrate it into their backend systems, thus actually allowing a view into their network. Ofcourse this isn't always what is wanted due to various political reasons etc., which is why I said that it _should_ be documented ;) Example: SixXS (www.sixxs.net) has the IPng tunnelbroker which delegates /60's from 3ffe:8114:2000::/48. We used to register every /60 in the 6bone database. But updating this every time an allocation is made and with the number of allocations isn't quite handy especially as the parameters enclosed in the inet6num could change a lot (eg endpoint changes). Thus we created our very own whois server (whois.sixxs.net) from which the data can be accessed, directly and up-to-date. eg: 8<---------------------------------------------- $ whois -h whois.sixxs.net 3ffe:8114:2000:240::/60 % This is the SixXS Whois server. % SixXS - http://www.sixxs.net. % The objects are in RPSL format. % Objects not beginning with SIXXS- % or ending in -SIXXS are % cached responses from remote sources. inet6num: 3ffe:8114:2000:240::/60 netname: SIXXS-NLAMS02-NET-JRM1-6BONE-34 descr: This route goes to an endpoint of JRM1-6BONE. descr: This route is routed to 3ffe:8114:1000::27 / 195.64.92.136. descr: IPng import country: NL admin-c: PBVP1-6BONE admin-c: JRM1-6BONE tech-c: PBVP1-6BONE tech-c: JRM1-6BONE rev-srv: purgatory.unfix.org. remarks: Prefixtype: Route remarks: This object is generated from the SixXS database remarks: Abuse reports should go to abuse@sixxs.net remarks: Information can be found at http://www.sixxs.net/ changed: info@sixxs.net 20020928 changed: info@sixxs.net 20030105 mnt-by: SIXXS-MNT source: SIXXS <SNIP other objects referred here> ---------------------------------------------->8 This allows troubleshooters to see where this prefix leads but it doesn't burden the main (in this case 6bone) database with new creations/updates/deletions. 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. Ofcourse all this is just my idea on this small sidesubject. Greets, Jeroen
Hi, On Tue, Jan 14, 2003 at 01:04:42PM +0100, Jeroen Massar wrote:
Example: SixXS (www.sixxs.net) has the IPng tunnelbroker which delegates /60's from 3ffe:8114:2000::/48. We used to register every /60 in the 6bone database.
<rant> Which brings up an interesting problem. According to the official guidelines, you're not supposed to assing anything that is not an /64 or /48. Of course this isn't helpful, as a home/DSL/tunnel user might want to use *two* networks, or *three*, but will never use more than 16 - and such a /60 is just perfect for them (I have considered doing the same for our dialup DSL customers). But the IETF in their infinite wisdom decided that this is not what people will want, so you're supposed to give them a /48. Which, for DSL and Tunnel usage, means "a sizeable chunk of the /32 that a LIR holds". </rant>
But updating this every time an allocation is made and with the number of allocations isn't quite handy especially as the parameters enclosed in the inet6num could change a lot (eg endpoint changes).
Now that part could be automated. Especially with the sync updates, this is fairly easy :-). On the other hand, adding referral mechanism for the inet6num: hierarchy would certainly be less strain to the RIPE DB. It's there for the domain: tree, so it shouldn't be too hard. Item for the working group (LIR or DB)? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55593 (55180) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
| On Tue, Jan 14, 2003 at 01:04:42PM +0100, Jeroen Massar wrote: | > Example: SixXS (www.sixxs.net) has the IPng tunnelbroker which delegates | > /60's from 3ffe:8114:2000::/48. We used to register every /60 in the | > 6bone database. | | <rant> | Which brings up an interesting problem. According to the official | guidelines, you're not supposed to assing anything that is not | an /64 or /48. [snip] | But the IETF in their infinite wisdom decided that this is not what | people will want, so you're supposed to give them a /48. Which, for | DSL and Tunnel usage, means "a sizeable chunk of the /32 that a LIR | holds". | </rant> <defence> Luckily, these /60 policies outdated the IETF recommendations by a year or two. And I'm not about to consider changing the pTLA tunnelbroker system at AS8954. The other (newer) deployments of the SixXS software do indeed issue /48s for each homeuser, following RIPE NCC's prior notice that 'if in doubt, allocate a /48' (AIAD oct'02). </defence> groet, Pim -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________
Hi, On Tue, Jan 14, 2003 at 02:12:25PM +0100, Pim van Pelt wrote:
<defence> Luckily, these /60 policies outdated the IETF recommendations by a year or two. And I'm not about to consider changing the pTLA tunnelbroker system at AS8954. The other (newer) deployments of the SixXS software do indeed issue /48s for each homeuser, following RIPE NCC's prior notice that 'if in doubt, allocate a /48' (AIAD oct'02). </defence>
My rant wasn't actually directed at you. I just noticed that you were having a similar policy issue to the one that came up here recently. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55593 (55180) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Tue, Jan 14, 2003 at 02:06:35PM +0100, Gert Doering <gert@space.net> wrote a message of 44 lines which said:
But the IETF in their infinite wisdom decided that this is not what people will want, so you're supposed to give them a /48. Which, for
RFC 3177 explains in great detail the rationale behind this recommendation. I suggest to read it.
Hi, On Tue, Jan 14, 2003 at 02:17:06PM +0100, Stephane Bortzmeyer wrote:
But the IETF in their infinite wisdom decided that this is not what people will want, so you're supposed to give them a /48. Which, for
RFC 3177 explains in great detail the rationale behind this recommendation. I suggest to read it.
The recommendation is pretty useless as it doesn't define what a "site" (or a "single edge network") is. I have been part of the discussions in the RIPE IPv6 WG, and have heard all the arguments in favour of the way it's set up now. Those arguments are pretty convincing, indeed... ...until you start thinking about "large scale assignments to *huge numbers* of DSL users with 1-2 networks each" and "how big shall the network be that a company assigns to their employees for home use" and "how much address space shall a university give to each of their students for at-home usage". None of those questions have any satisfactory answer under the current model. Especially the second one is what we have here right now. Shall a company (being "a site") get a /48? Or shall each of the individual employees of that company (his home network being "a site") get a /48, thus making the company need a /42? How can we assign a /42 to something that's as small (network-wise) as the RIPE NCC? If we accept the argument that "there is no shortage of /48s" and hand out /48s freely to all individual employees of a customer, or to each individual student of a university, then this will deplete the LIRs /32 pretty quickly (a university with 35.000 students might easily use up a /32 on their own). Which is not what people envisioned when the current IPv6 allocation policy was made, obviously. Also, this practice would be violating RFC 3177: - Very large subscribers could receive a /47 or slightly shorter prefix, or multiple /48's. - which makes it pretty clear that an enterprise should not receive a /42 just because their employees want a /48 each. Now how are you going to solve that riddle? (A viable solution would be to give every LIR a /20. But last time I proposed that, people were Not Amused, accused me of wasting address space and flatly refused to accept that as a new policy...) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55593 (55180) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
[Probably opening a can of worms here...] On Tue, 14 Jan 2003 14:54:50 +0100, Gert Doering <gert@space.net> said:
On Tue, Jan 14, 2003 at 02:17:06PM +0100, Stephane Bortzmeyer wrote:
But the IETF in their infinite wisdom decided that this is not what people will want, so you're supposed to give them a /48. Which, for
RFC 3177 explains in great detail the rationale behind this recommendation. I suggest to read it.
The recommendation is pretty useless as it doesn't define what a "site" (or a "single edge network") is.
The reasoning in that document is heavily based on the statement that there is enough address space to give a /48 to everybody and their dogs. With this assumption (which, I believe, is fairly sound by itself), you don't need a precise definition of a site (``when in doubt, assign a /48''). I think that RFC3177 is self-consistent in that respect. But see below. [snip]
If we accept the argument that "there is no shortage of /48s" and hand out /48s freely to all individual employees of a customer, or to each individual student of a university, then this will deplete the LIRs /32 pretty quickly (a university with 35.000 students might easily use up a /32 on their own). Which is not what people envisioned when the current IPv6 allocation policy was made, obviously.
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.
Also, this practice would be violating RFC 3177:
- Very large subscribers could receive a /47 or slightly shorter prefix, or multiple /48's.
- which makes it pretty clear that an enterprise should not receive a /42 just because their employees want a /48 each.
Now how are you going to solve that riddle?
I think this contradiction exists mainly within the current allocation policy. RFC3177 seems to be flexible (or vague ;-) enough. With a policy in which such an enterprise can act as a (sub-)LIR as well as a site, they could get a large block from which they can assign a /48 to each employee as well as to their own network. Thus, their enterprise network would be as much a site as the homes of the employees, even though it provides transit to them. But this is already done today, isn't it? We (SWITCH) hold a /32 as LIR but our network (which I consider to be a site) is a /48 out of that block.
(A viable solution would be to give every LIR a /20. But last time I proposed that, people were Not Amused, accused me of wasting address space and flatly refused to accept that as a new policy...)
That seems to be the dilemma: on the one hand, we should be a lot more liberal if we want to implement the recommendations of RFC3177. On the other hand, we are very reluctant to do that as long as we don't have very strong arguments that such a policy will actually work in the long run. Alex -- __________ SWITCH - The Swiss Education and Research Network __________ Alexander Gall, SWITCH, Limmatquai 138, CH-8001 Zurich, Switzerland gall@switch.ch Tel: +41 1 268 1522 Fax: +41 1 268 1568
On Tue, Jan 14, 2003 at 14:06:35 +0100, Gert Doering wrote:
Of course this isn't helpful, as a home/DSL/tunnel user might want to use *two* networks, or *three*, but will never use more than 16 - and such a /60 is just perfect for them (I have considered doing the same for our dialup DSL customers).
Be careful about "will never use more than 16" :-) In the future, home users may wish to give each family member a couple of /64s to carry around with them as their personal networks (PANs). There are plenty of /48s. Address conservation is not an issue with IPv6 (although address hierarchy is). xDSL and FTTH customers will get their /48 from an ISP. When that ISP has used up its /32, it can get another address block from the RIR. Companies and universities are another thing. Usually, they are not ISPs. However, if they provide xDSL, fiber or whatever connections to their employees or students, they _are_ ISPs and should have address space to use for that. If they are not ISPs, why would they assign a prefix to their employees or students? Maybe in the short term, when that's the only way to get IPv6 connectivity. But after that? For a VPN? I suppose a single /64 should be enough for that. rvdp
participants (7)
-
Alexander Gall -
Gert Doering -
Jeroen Massar -
Pim van Pelt -
Ronald van der Pol -
Stephane Bortzmeyer -
Wilfried Woeber, UniVie/ACOnet