June 2002 - ipv6-wg - mailman.ripe.net

Re: Getting addresses
by Wilfried Woeber, UniVie/ACOnet 25 Oct '02

25 Oct '02

Hi Rudolf! >I am new to these discussions on the list, so if I am saying something >stupid, please tell me so. Not at all! The worst thing that is happening here is that we re-iterate things. So what.... >>I don't have a point of view. A lot of people are telling me they will >>choose the /48 road. Without a detailed definition of site, almost >>everyone's view will have to be accepted. That's what I am seeing in all >>these discussions. > >That is what has been bothering me the most in the whole discussion about >who gets a /32 assignment and who doesn't. This is one thing that is so surprising for me in these discussions: There seems to be an implicit assumption that we SHOULD come up with all sorts of criteria to BLOCK distributing IPv6 addresses, rather than getting the technology rolled out :-(). As an aside, I still see IPv6 address space as a *global resource*, not something which a (roughly) self-defined group of entities partitions amongst them (tier-X ISPs). Becoming an LIR is possible for (almost) every type and shape and size of organisations (at least in the RIPE region) - but it is not for free. There are quite some good reasons for distributing globally unique IPv6 addresses to entities which would not fit the "classical" ISP (or even tier-X ISP) definition. And those amongst us who worry about end-to-restoration, making things simple(r), looking into the future, should recognize that there is no "rfc1918" space in v6-land. (Yes, I know about the site-local address concept. But why should we plant time-bombs ticking when there are plenty of those magic bit combinations around?). >Both the number of /48 >assignments as well as the determination of what an end-site is, are >completely arbitrary I agree. It's the same level of "arbitray-ness" that is wired into "200 sites", trying to define an ISP, and the like. It's better than nothing at all (i.e. no consensus) - at least for now. >and therefore in the long run unworkable. We'll see. We havent tried yet. And by the way, we have tried to define "ISP" in v4-land for years, and we failed. > Almost >everyone that is an LIR now, is able through one trick or another to >justify an allocation of a /32 Actually, this was the point of view that had emerged in the RIPE region during the Jan'02 meeting. "Every LIR should get an allocation" if they can document the need for 1 address. The "tricking" started to come into the game when we again tried to impose (artificial) criteria/ limits/ restrictions/... Btw, I still do remember the days (around '93) when a LIR was allowed to give away a /23 to every "site", no questions asked. And it didn't *break* the Internet, it made it *succeed*! In the end every policy is a compromise. Some of us don't like the version we do have on the table right now because we think it is too restrictive. Some of us dislike the thing because we perceive it as too liberal. Such is life. > and as Joao points out, the RIR's won't be >able to do anything against it. The RIRs should not act *against* "something"! They are supposed to execute a consensus, written down in a document and agreed by the community! It took a loong time, and many discussions, to arrive at the doc we do have on the table right now. And there are things in it which are "fuzzy". That was done deliberately, after trying (and failing) to come to more precise (and sometimes restrictive) definitions that would still be acceptable to all the 3(4) regions. On the other hand quite a few things were straightend out (like the exclusive reference to a /48 holder), and I'd really urge all of you to *completely read* the final doc. > And then I wonder if in the long run we >won't see a global routing mess, because many more organisations will be >able to register as LIR and justify a /32 in the same way. This is exactly >what the requirement for 200 potential sites tries to achieve, but fails to >do. Well, again one of those "assumptions" that this is bad :-) I still think that we can accommodate a *lot* of IPv6 routing with the slack from the (predicted) growth in v4 that did NOT happen in v4-land.... >The community should be able to come up with a better definition of who >should be allowed to get a /32 and who is condemned to go to an upstream >provider. This should be more objective than the current rule and not >result in the problems that we see now for RIR's and IXP's and smaller >NREN's and ISP's, . Welcome to the show. I hope you would be around to help when we have to re-work the thing to adapt it to the evolving Internet :-) Just one comment on the use of "smaller" here: we couldn't come up with a good set of criteria to define a "smaller" "whatever". What are the criteria? Real estate? Gigabit/sec? Terabit storage? number of contracts? number of web pages? annual turnover? annual profit (or loss :-)? The tier-1 ISP of yesterday is the chapter 11 case of today and a department of another ISP tomorrow. As I said during the discussion, (given the IETF recommendation) a SOHO customer of a "commercial" ISP s/would qualify for a site .eq. a /48. Probably a handful of physical subnets would be used. And it is easy to have a few hundred of those, eventually (probably). A university, or a regional edu-network could be structured alongside a single /48 as well. Such a "site" could happen to serve some 5000..10000 ..50000 users in quite some hundred physical subnets (LAN, ISDN, ADSL, wire-less). Which of those network would be the "smaller" one?? Is it really "cheating" if we start to treat a primary and secondary school as a site with their own /48? Or the other way 'round, why is the "commercial ISP" not treated as a site with *1* /48? I am stretching things here just a little bit, on purpose... >I think we can evade a global routing slump if we allow the RIR's to >continue the excellent work they have done in the last couple of years. >They have conserved adresses well. In one of the doc.s there is that famous statement that conservation and routing aggregation can, or tend to, be conflicting goals. >But we should provide them with adequate >rules to work with, so that they can aggregate well in the IPv6 future too. > >>The problem is the lack of arguments for an RIR on what is the right thing >>to do. >> >>Joao > >Let us provide them with the right arguments to do the right thing. Fair enough, but - >Maybe we should take that discussion back to the global v6 list. wouldn't it be prudent to try to *implement* the new policy, learn by doing so, and *then* go back to the drafting table?! I do not believe anybody claiming that we/he/she can find out *now* what the best solution is in a few year's time. The 'net is constantly evolving.... >Greetings, > >Rudolf van der Berg >Dutch German Internet Exchange >http://www.ndix.net OK, I think I'll leave it at that for this discussion :-) Thanks for your good questions and observations! Cheers, 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

5 4

Status field for inet6num objects
by Joao Luis Silva Damas 08 Jul '02

08 Jul '02

[** Mail posted to both APNIC and RIPE lists in the hopes of trying to find a solution suitable for all users of RIPE or RIPE-derived software **] Dear all, the inet6num, like the inetnum object, has a field named "status" which stores some information about the nature or position of a block of addresses in the delegation chain, from the RIR through to the end user. Currently, the status field for inet6num object is generated by the Database software based on the size of the address block and its possible values are: o TLA o SubTLA o NLA o SLA This notation has been deprecated and it is time to adapt the database. Discussions on this matter have identified the usefulness of having the capability to distinguish between allocations made by the RIR, allocations made by an LIR or their customers and assignments to end users. As such, we propose to modify the "status" attribute of the inet6num object to be: a) not-generated. This means users must assign a value to the status attribute when creating the object, just as in the inetnum object b) have the following possible values: RIR-allocated LIR-allocated Assigned to be used according to the following set of rules: The RIR-allocated status can only be used in objects representing allocations created directly by the RIR. The LIR-allocated status can be used by LIRs and their customers to represent blocks of addresses that are not assigned to specific end users. There can be several levels of objects with this status. The Assigned status must be used in objects representing assignments to end users (households, companies, enterprises, etc) We hope that with this modification the information in the Database will more accurately describe the registration of IPv6 address space. A possible transition to the new values could be: 1) RIRs modify status fields for allocations 2) Any new objects and modifications to existing ones must have a value for the status field corresponding to the ones described above. Otherwise the update will fail. 3) RIRs contact LIRs to have the status of assignments and sub-allocations updated. Best regards, Joao Damas RIPE NCC

6 8

New IPv6 Documents available
by RIPE NCC Document Announcement Service 27 Jun '02

27 Jun '02

New/Revised RIPE Document Announcement, apologies for multiple e-mails. -------------------------------------- Revised/new documents available from the RIPE document store. Ref: ripe-246 Title: IPv6 Address Allocation and Assignment Policy Author: ARIN, APNIC, RIPE NCC Date: 27 June 2002 Format: PS= 812450 TXT=31632 Obsoletes: ripe-196 Ref: ripe-247 Title: Initial IPv6 Allocation Request Form in the RIPE NCC Service Region Author: Leo Vegoda Date: 27 June 2002 Format: PS=16615 TXT=4226 Obsoletes: ripe-195 Ref: ripe-248 Title: Supporting Notes to the Initial IPv6 Allocation Request Form in the RIPE NCC Service Region Author: Leo Vegoda Date: 27 June 2002 Format: PS=28439 TXT=12788 Ref: ripe-249 Title: IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region Author: Leo Vegoda Date: 27 June 2002 Format: PS=16477 TXT=4126 Ref: ripe-250 Title: Supporting Notes for the IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region Author: Leo Vegoda Date: 27 June 2002 Format: PS=34008 TXT=15211 Short content description ------------------------- This set of IPv6 documents define registry policies for the assignment and allocation of globally-unique IPv6 addresses to Internet ServiceProviders (ISPs) and other organisations. The core document: "IPv6 Address Allocation and Assignment Policy" (ripe-246) obsoletes the "Provisional IPv6 assignment and allocation policy document" (ripe-196). It was developed through joint discussions among the APNIC, ARIN and RIPE communities. The other documents support the policy document, and provide Local Internet Registries with request forms for IPv6 address space. Supporting notes for the request forms can be found in the supporting notes documents. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via WWW at the following URLs: "IPv6 Address Allocation and Assignment Policy" (ripe-246) is available at: http://www.ripe.net/ripe/docs/ipv6policy.html "Initial IPv6 Allocation Request Form in the RIPE NCC Service Region" (ripe-247) is available at: http://www.ripe.net/ripe/docs/ipv6-initial.html "Supporting Notes for the Initial IPv6 Allocation Request Form in the RIPE NCC Service Region" (ripe-248) is available at: http://www.ripe.net/ripe/docs/ipv6-supp-initial.html "IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region" (ripe-249) is available at: http://www.ripe.net/ripe/docs/ipv6-assignment-request.html "Supporting Notes for the IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region" (ripe-250) is available at: http://www.ripe.net/ripe/docs/ipv6-supp-assignment.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-246.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-246.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-247.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-247.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-247.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-247.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-247.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-247.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-247.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-247.txt plain text version Kind Regards, RIPE NCC Document Announcement Service

1 0

RE: [apnic-talk] Status field for inet6num objects
by Guy Davies 20 Jun '02

20 Jun '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: Nigel Titley [mailto:nigel@titley.com] > > On Wed, 2002-06-12 at 07:11, Daniel Karrenberg wrote: > > At 06:00 AM 6/12/2002, Geoff Huston wrote: > > >However, the distinction between "ALLOCATED" and > "ASSIGNED" is perhaps a bit subtle. > > > > When these attributes were created, those particular words > were in deemed both descriptive and clear. > > Maybe the language concerned has shifted underneath in the > meantime ;-). > > As a native speaker of one of its dialects, would you make > a suggestion for improvement? > > Well actually as a native speaker of (another) of its dialects, > I've never considered the distinction of ALLOCATED and ASSIGNED to > be other than subtle. I'd much prefer DELEGATED and ASSIGNED or > some such. This may be a matter of taste however. I tend to agree with Nigel, although I'd go for something even plainer like DELEGATED-TO-LIR and ASSIGNED-TO-END-USER (I know they're a bit verbose but they're absolutely clear ;-) It also makes clear that addresses assigned to an LIR in the role of END-USER are exactly that. That way, an individual who is struggling with English as a second language (or even their first language ;-) can be absolutely clear of the status of a range of addresses. Just my two pence... Regards, Guy -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPQca4I3dwu/Ss2PCEQJv6ACeMa1ZbnoN3P7r6VaBANGPa1yXN9UAoMLQ cJpgKn6FvDPmyD1X02WLXJF3 =yl1x -----END PGP SIGNATURE----- This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavors to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

8 8

RE: [apnic-talk] Status field for inet6num objects
by Michael.Dillon＠radianz.com 13 Jun '02

13 Jun '02

>For me these two phrases, DELEGATED-TO-LIR and >ASSIGNED-TO-END-USER, hit the spot precisely! >excellent suggestion Guy! >Is it appropriate to request consideration of these terms as replacements >for ASSIGNED and ALLOCATED? Wouldn't it be a good idea to standardize the terminology with ARIN and others? In that case, the term LIR would be considered obscure and meaningless. Since all LIRs are service providers of some sort, either ISPs or an internal network service provider, I think that a standard terminology should try to use generic terms. That would mean either DELEGATED-TO-SVC-PROVIDER or DELEGATED-TO-NSP if you like acronyms (Network Service Provider). In any case, because the distinction between "allocated" and "assigned" has been unclear in the past and because there is a significant shift in terminology from "allocated" to "delegated" this change should be incorporated in an informational RFC. This document would help in clarifying that there is indeed a difference between the two states of an address block and would also help in promoting the use of this terminology amongst the community that deal with IP address delegations and assignments. DELEGATED-TO-NSP and ASSIGNED-TO-USER are two terms that would be clear worldwide. Michael Dillon Network Product Engineering Radianz

2 1

Re: [apnic-talk] Status field for inet6num objects
by Daniel Karrenberg 13 Jun '02

13 Jun '02

At 06:00 AM 6/12/2002, Geoff Huston wrote: >However, the distinction between "ALLOCATED" and "ASSIGNED" is perhaps a bit subtle. When these attributes were created, those particular words were in deemed both descriptive and clear. Maybe the language concerned has shifted underneath in the meantime ;-). As a native speaker of one of its dialects, would you make a suggestion for improvement? Daniel

5 4

Re: [hostmaster-staff] Re: [apnic-talk] Status field for inet6num objects
by Michael.Dillon＠radianz.com 13 Jun '02

13 Jun '02

>Allocation and assign do have definitions - could these be improved >to clarify the meaning? Or does 'delegate' simply convey a much >clearer intention with the address space? Delegation is clearer for two reasons. Firstly, it implies that the the delegator is passing on some responsibility for the address space. The organization receiving a delegation is responsible for managing and administering the addresses. In the case of an assignment, this is less true. For instance, ISPs regularly reassign addresses after a customer disconnects and everyone seems to understand that addresses assignments are controlled by the assigner and can be withdrawn. The second reason has more to do with psychology. Because the terms "allocation" and "assignment" are similar in meaning and visually similar, they are easily confused by a lot of people. They both begin with "a" followed by a double consonant and end with a latin suffix. Of course, clear definitions are always a good thing as well. Michael Dillon Network Product Engineering Radianz

1 0

Re: [apnic-talk] Status field for inet6num objects
by leo vegoda 13 Jun '02

13 Jun '02

On Thu, Jun 13, 2002 at 10:42:42AM +0100, Michael.Dillon(a)radianz.com wrote: Re: RE: [apnic-talk] Status field for inet6num objects [...] > Wouldn't it be a good idea to standardize the terminology with ARIN and > others? Section two of the IPv6 policy document is the "Definitions" section. It defines RIR, NIR, LIR, ASN, Allocation and Assignment among other things. Regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager

1 0

Re: [apnic-talk] Status field for inet6num objects
by Robert Kiessling 12 Jun '02

12 Jun '02

Nigel Titley <nigel(a)titley.com> writes: > > This is still missing a status for allocations done by LIRs to someone > > Don't you mean assignments? :-) No. > > who is neither LIR nor end user ("NLA"). > > Examples? (I'm probably just being stupid) 5.3 of the 2002-04-25 draft: "LIR-to-ISP allocation". LIRs are free to suballocate the allocation they got from a RIR. Such a suballocation is neither an assignment nor a RIR-allocation, so should get a separate status attribute (as found in the original proposal). Robert

2 1

RE: [apnic-talk] Status field for inet6num objects
by kevin.bates＠bt.com 12 Jun '02

12 Jun '02

seems better but not perfect - the important thing is to get all databases looking the same and using the same terms? strictly speaking it is not "ASSIGNED-TO-END-USER" its "ASSIGNED-TO-SUBNET-USER" for example it could be part of a DHCP dial up pool and thus only " leased" for the duration of that connexion. > At 11:56 AM 6/12/2002, Guy Davies wrote: > >I tend to agree with Nigel, although I'd go for something even > >plainer like DELEGATED-TO-LIR and ASSIGNED-TO-END-USER (I know > >they're a bit verbose but they're absolutely clear ;-) It also makes > >clear that addresses assigned to an LIR in the role of END-USER are > >exactly that. That way, an individual who is struggling with English > >as a second language (or even their first language ;-) can be > >absolutely clear of the status of a range of addresses. > > This is an excellent idea. However I would use > ALLOCATED_TO_LIR and ASSIGNED_TO_END_USER. > That way we clarify the subtle difference while > maintaining consistency with existing documentation. > > (If I remember correctly the term DELEGATED was suggested at the time, > but not used because of its usage in the DNS context as well as > the connotation of total transfer of authority over the resource which > is not quite the case.) > > Daniel

2 1