July 2005 - address-policy-wg

New Document available: RIPE-349
by RIPE NCC Document Announcement Service 27 Jul '05

27 Jul '05

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE Document store. Ref: ripe-349 Title: Address Space Managed by the RIPE NCC Author: Leo Vegoda RIPE NCC Date: 27 July 2005 Format: PDF=31257 TXT=2986 Obsoletes: ripe-348 Short content description ------------------------- This document details the address space managed by the RIPE NCC and the longest prefixes allocated or assigned from different address ranges. The new version was needed to correct errors in the previous document. Accessing the RIPE Document store --------------------------------- You can access this RIPE Documents in HTML format at: http://www.ripe.net/docs/ripe-349.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 document on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-349.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-349.txt plain text version

1 0

The Register: ICANN prez delivers internet vision
by Hans Petter Holen 20 Jul '05

20 Jul '05

1 0

Presentation of the WGIG Report
by Axel Pawlik 20 Jul '05

20 Jul '05

Dear Colleagues, The WGIG Report was presented in Geneva on 18 July at a meeting open to all stakeholders. The Report of the Working Group on Internet Governance was previously transmitted on 14 July by United Nations Secretary-General Kofi A. Annan to the President of the Preparatory Committee of the World Summit on the Information Society, Ambassador Janis Karklins, and the WSIS Secretary-General, Mr Yoshio Utsumi. The document is available from the WGIG web site in all UN languages at: http://www.wgig.org/WGIG-Report.html More details on the meeting and the transcripts from the morning and afternoon session proceedings are also available at: http://www.wgig.org/index.html Regards, Axel Pawlik Managing Director RIPE NCC

1 0

New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 20 Jul '05

20 Jul '05

Dear Colleagues, The RIPE NCC received the IPv6 address range 2A01:0000::/23 from the IANA in July 2005. We will begin making allocations from this block in the near future. 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: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html This document has been updated to to provide extra information about the IPv6 address space we manage, following some requests we received. I hope people find the new format useful. Regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

IPv6 Policy Clarification - Initial allocation criteria "c)"
by Laura Cobley 19 Jul '05

19 Jul '05

Dear Colleagues, As explained in the email sent on Mon, 14 Jun 2004: http://www.ripe.net/ripe/mail-archives/address-policy-wg/2004/msg00240.html This is the second mail request for clarification of the IPv6 Address Allocation and Assignment Policy. Below is an excerpt from the IPv6 Address Allocation and Assignment Policy: 5.1.1. Initial allocation criteria "c)" "To qualify for an initial allocation of IPv6 address space, an organisation must [...] plan to provide IPv6 connectivity to organisations to which it will assign /48s by advertising that connectivity through its single aggregated address allocation" LIRs who operate closed/private networks appear not to qualify because the address space in these networks will not be advertised. Was this the community's intention? Best Regards, Laura Cobley Registration Services RIPE NCC

9 12

Administrative: New chair email address
by Hans Petter Holen 17 Jul '05

17 Jul '05

Dear all, Following my change of jobs last year from Tiscali to Visma, and as a consequence of Tiscali having sold its Nowegian operations to the former incumbent Telenor, its Swedish opreations to Spray-Lycos and its Danish operations to Tele2; I am changing my personal email address from my private Tiscali subscription to hph(a)oslo.net This will also remove the technical difficulties of delayed email and unsolicited virus scan messages my former employee has imposed on me. The tiscali.no address will still work for some time - but maybe not for more than a year into the future. The Oslo.net domain is however mine to keep - the only remaining memory of the first Norwegian comercial consumer ISP Oslonett - for norwegian readers there are some historic material at the web site. Best Regards Hans Petter Holen Private email: hph(a)oslo.net PS: Appologies for the followin messages to the list: this is most likely due to some new anti-virus software imposed upon me. Antigen_EXFE01HI(a)smarthost3.tiscali.dk wrote: >The entire message "RE: [address-policy-wg] last Call: Policy proposal #beta HD ratio policy proposal", originally sent to you by address-policy-wg-admin(a)ripe.net (address-policy-wg-admin(a)ripe.net), has been forwarded to you from the Antigen Quarantine area. >This message may have been re-scanned by Antigen and handled according to the appropriate scan job's settings. > > > ><<Entire Message.eml>> > >

1 0

Re: [address-policy-wg] FWD: [GLOBAL-V6] draft-narten-iana-rir-ipv6-considerations-00.txt
by Thomas Narten 15 Jul '05

15 Jul '05

Niall Murphy <niallm(a)enigma.ie> writes: > Thomas, all, > > I'd welcome discussion/feedback on it, and this list seems as good a > > place as any. > > > > http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6-consideratio… > This is nit-picking, but for the sake of clarity: > 2.7. Utilization > In IPv4, the utilization of a chunk of address space is defined as > the ratio of the actual number of host assignments to the theoretical > maximum number of host assignments. For example, a /24 in IPv4 can > number 256 hosts [...] > A /24 can't number 256 hosts; it can number 254. Well, for the purposes of this draft, it's probably best to understand how the RIRs themselves measure utilization. Surely, they just count the raw numbers and don't try to exclude broadcast addresses and such. Thomas

1 0

FWD: [GLOBAL-V6] draft-narten-iana-rir-ipv6-considerations-00.txt
by Thomas Narten 15 Jul '05

15 Jul '05

FYI. The global-v6 list appears to still be active, and perhaps we can revive the list to talk about things that really cross the entire RIR community. Thomas ------- Forwarded Message From: Thomas Narten <narten(a)us.ibm.com> To: global-v6(a)lists.apnic.net Date: Thu, 14 Jul 2005 09:40:34 +0200 Subject: [GLOBAL-V6] draft-narten-iana-rir-ipv6-considerations-00.txt I think/hope the global-v6 is still in operation, so this is a bit of a test... I've written a document that attempts to give background and describe the bigger picture w.r.t. IPv6 address space management and the various issues that are now being discussed (e.g., hd ratio, /48 boundary, etc.). This document is intended to provide information and explain the broader landscape, rather than propose specific changes, etc. I'd welcome discussion/feedback on it, and this list seems as good a place as any. http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6-consideratio… Likewise, there is another document that will be discussed at the upcoming Paris IETF meeting. http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-00… That document will be discussed in the IPv6 WG: http://www.ietf.org/html.charters/ipv6-charter.html mailing list: https://www1.ietf.org/mailman/listinfo/ipv6 Finally, significant discussion on the general topic has already place (and continues) in the ARIN and RIPE regions. Folk may want to review/follow some of the discussions that have taken place there: http://www.ripe.net/mailman/listinfo/address-policy-wg http://lists.arin.net/mailman/listinfo/ppml (I believe the pointers to the ARIN/RIPE discussions have been sent to APNIC lists, but I don't believe a lot of discussion has taken place there - yet). Thomas _______________________________________________ global-v6 mailing list global-v6(a)lists.apnic.net http://mailman.apnic.net/mailman/listinfo/global-v6 ------- End of Forwarded Message

5 4

RE: [address-policy-wg] last Call: Policy proposal #beta HD ratio policy proposal
by BIDRON Alain ROSI/DAS 14 Jul '05

14 Jul '05

According to the proposal documented in the APNIC region, http://www.apnic.net/docs/policy/discussions/prop-020-v001.txt the proposal is based on the HD value 0.96. I think it is better to have the same value for all RIRs. Best regards. Alain -----Message d'origine----- De : Koepp, Karsten [mailto:Karsten.Koepp@lambdanet.net] Envoyé : mardi 12 juillet 2005 12:20 À : BIDRON Alain ROSI/DAS Cc : address-policy-wg(a)ripe.net; Hans Petter Holen Objet : RE: [address-policy-wg] last Call: Policy proposal #beta HD ratio policy proposal Bonjour Alain, thanks for your reply. Why have you changed the HD value recommended by APNIC and ETNO from 0.966 to 0.96? Using HD of 0.966 APNIC was projecting an increased IPv4 address consumption of 22%. In case of fr.telecom the lower value drives the required address consumption from 58% to 53%. Please explain this change. For others: APNIC: https://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ap-hd-ratio. pdf ETNO: http://www.etno.be/pp/EC064%20-%20NANI%20EC%20on%20IPv4%20AD%20ratio.pdf I am personally still not convinced but I have no experience in running such networks as Alain does. regards Karsten > -----Original Message----- > From: BIDRON Alain ROSI/DAS [mailto:alain.bidron@francetelecom.com] > Sent: Tuesday, July 12, 2005 10:19 AM > To: Koepp, Karsten; Hans Petter Holen > Cc: address-policy-wg(a)ripe.net > Subject: RE: [address-policy-wg] last Call: Policy proposal #beta HD > ratio policy proposal > > > Dear Karsten, > When you manage an X-large registry you have several levels > of management. > In such a situation, meeting the 80% criteria is much more > difficult (if possible) than with a small registry with only > one level. > The proposal is clearly not to advantage or to disadvantage > some registries but simply to take into account in fair way > different situations in order to have enough flexibility for > a better management. > > Regarding the support from the community, I have to mention > that this proposal was considered by ETNO, whose members > representing are a large part of X large registries in the > RIPE region, and unanimously supported. > > You can find this expression for support at > www.etno.be Document EC064. > > Leo Debecker posted this contribution from ETNO to the mailing list. > Be aware that this support comes from the following ETNO members. > This is not one voice but 41. > · Auna Telecomunicaciones > · Belgacom > · BH Telecom (Bosnia and Herzegovina) > · BT (British Telecom) > · BTC (Bulgarian Telecommunications Company) > · Cesky Telecom > · Community of Yugoslav PTT > · Croatian Telecom > · Cyprus Telecommunications Authority > · Deutsche Telekom > · Eircom > · Elion Enterprises Ltd > · Elisa Communications Corporation > · Entreprise des Postes et Télécommunications Luxembourg > · Finnet Group > · France Telecom > · Invitel > · Koninklijke KPN > · Lattelekom > · Makedonski telekomunikacii > · Maltacom > · Matáv Hungarian Telecommunications Company > · Netia S.A. > · OTE > · Portugal Telecom > · Rom Telecom > · Síminn (Iceland Telecom Ltd.) > · Slovak Telecom > · Societatea Nationala de Radiocomunicatii (SNR) > · Swisscom > · TDC > · Tele 2 > · Telecom Italia > · Telefonica > · Telekom Austria > · Telekom Slovenije > · Telekomunikacja Polska > · Telenor > · TeliaSonera > · Türk Telekomünikasyon > · VIPnet > Regards > > -----Message d'origine----- > De : address-policy-wg-admin(a)ripe.net > [mailto:address-policy-wg-admin@ripe.net]De la part de Koepp, Karsten > Envoyé : jeudi 7 juillet 2005 12:34 > À : 'Hans Petter Holen' > Cc : address-policy-wg(a)ripe.net > Objet : RE: [address-policy-wg] last Call: Policy proposal #beta HD > ratio policy proposal > > > Hello Hans Petter and al, > > I am AGAINST the proposal. > > I would like Alain to better explain his need for better IP > address management. He is the only voice I have seen *for* > the proposal. Nobody is supporting Alain, instead Iljitsch > has brought profound comments *against*, and there were some > cynic comments - also *against*. > > From my point of view, I would like to see the current policy > remain in place, because with IPv4 we much more have a conservation > than an aggregation goal (or an internal aggregation need) > Large LIRs already receive /10s and I cannot see the proposal > will have "some limited impact" on address consumption. If > giant LIRs will only be mandated to occupy 52% instead of 80% of > their v4-IPs (I have done this calculation for DTAG and FT), this > is in my view going to cut our resources significantly. > > So, does the new PDP request a counter proposal to maintain > current policy, I guess no, just enough people have to say > no. Also, people in support of the proposal please raise your > hands. > > regards Karsten > eu.lambdanet > > > -----Original Message----- > > From: Hans Petter Holen [mailto:hpholen@tiscali.no] > > Sent: Friday, July 01, 2005 12:37 AM > > Cc: address-policy-wg(a)ripe.net > > Subject: [address-policy-wg] last Call: Policy proposal > #beta HD ratio > > policy proposal > > > > > > Hans Petter Holen wrote: > > Following the discussion on the mailinglist prior to and > > after posting > > the formal proposal I have seen no proposals to modify the > > proposal and > > would like to move the proposal into the conclustion phase in > > the policy > > development process > http://www.ripe.net/ripe/draft-documents/pdp.html > > > > Last cal will end at July 15th. > > > > Best Regards > > > > Hans Petter Holen > > WG Chair > > > > > Thanks Alain, > > > I'll as the new PDP is not in operation yet, I'll add this > > to my list > > > as #beta v1 > > > > > > I propose that we enter into the Discussion phase for 4 > weeks from > > > date until April 4. > > > > > > -hph > > > > > > BIDRON Alain ROSI/DAS wrote: > > > > > >> Dear Colleagues > > >> Referring to the minutes of the last RIPE Policy Working Group > > >> meeting and to the action list as updated during that > > meeting, I have > > >> to make a formal proposal on use of HD ratio for IPV4. > > >> Here is this policy proposal. > > >> In order to be consistent with the PDP Draft proposal > > coming from Rob > > >> Blokzijl I have used the template provided in the new > PDP proposal. > > >> Best regards. > > >> Alain > > >> > > >> > > >> _________________________________________________________ > > >> 1. Policy Proposal Name: IPv4-HD-Ratio > > >> 2. Author > > >> a. name: Alain Bidron > > >> b. e-mail: alain.bidron(a)francetelecom.com > > >> c. telephone: +33 1 44 44 27 75 > > >> d. organisation: France Telecom > > >> 3. Proposal Version: V0 > > >> 4. Submission Date: 02/02/2005 > > >> 5. Suggested WG for discussion and publication: Address Policy WG > > >> 6. Proposal type: modify > > >> 7. Policy term: permanent > > >> 8. Summary of proposal: Internet address space is managed > > >> hierarchically: > > >> - IANA allocates space to Regional Internet Registries (RIRs). > > >> - RIRs allocate space to Local Internet Registries (LIRs). > > >> - LIRs assign space to End Users. > > >> > > >> At each level, some address space may be reserved for future > > >> expansion and/or efficient aggregation. As more > > hierarchical levels > > >> are introduced, the overall efficiency of the address > space usage > > >> decreases. > > >> > > >> The HD ratio (Host-Density ratio) is a way to measure > > address space > > >> usage [RFC 3194]. The HD ratio value can relate to a > percentage of > > >> usage, which decreases as the amount of address space > grows. This > > >> allows for the decreasing efficiency that occurs with more > > >> hierarchical levels. > > >> > > >> The HD ratio is currently used to measure IPv6 address > space usage > > >> [ipv6-address-policy]. The IPv6 Address Allocation and > Assignment > > >> Policy considers a block of IPv6 address space to be > > 'used' when its > > >> HD ratio reaches 0.80. This is a manageable figure > > ("values of 80% or > > >> less correspond to comfortable trade-offs between pain and > > >> efficiency" [RFC 3194]). > > >> > > >> This document proposes using the HD ratio to measure IPv4 > > usage. The > > >> proposed value of the HD ratio for IPv4 is 0.96. > > >> > > >> 9. Policy text: > > >> a. Current: "An LIR may receive an additional allocation > > when about > > >> eighty percent (80%) of all the address space currently > > allocated to > > >> it is used in valid assignments or sub-allocations." > > >> b. New: "An LIR may receive an additional allocation when > > its total > > >> allocated address space usage meets the HD-Ratio value of 0.96." > > >> > > >> 10. Rationale: > > >> > > >> a. Background > > >> The current document, "IPv4 Address Allocation and Assignment > > >> Policies for the RIPE NCC Service Region" [ipv4-address-policy], > > >> considers a block of IPv4 addresses to be 'used' when 80% of the > > >> addresses within the block have been sub-allocated or > > assigned. This > > >> is applied to all address blocks, regardless of size. > > >> Current policies assume a hierarchical system of address space > > >> delegation. However, they do not make any allowance for > > hierarchical > > >> management within allocated address space. For LIRs in > > particular, a > > >> hierarchical approach is often required for assignment > of address > > >> space to service elements such as customer networks, individual > > >> Points of Presence (PoPs), regionalised topologies, and > > even distinct > > >> ISP products. Small network infrastructures may require simple > > >> hierarchies, but large infrastructures can require several > > levels of > > >> address space subdivision. These levels of hierarchy are not > > >> recognised by the current policy framework and are highly > > restricted > > >> by the "80% rule". As a result, managing large blocks is often > > >> difficult, requiring large internal routing tables > and/or frequent > > >> renumbering of internal address blocks. > > >> > > >> One of the goals of the RIR system is to avoid unnecessary > > depletion > > >> of IPv4 address space. However, address management > > policies must also > > >> be practical in terms of how much management overhead > they cause. > > >> When large amounts of address space are involved, the "80% > > rule" can > > >> result in more work for an LIR. > > >> > > >> Basing usage on the HD ratio should lead to equal levels of > > >> management overhead across the board, rather than penalising the > > >> holders of large address blocks. > > >> > > >> b.Impact > > >> To see a rough estimation of the immediate impact of this > > proposal, > > >> an HD Ratio value of 0.96 was applied to the average amount of > > >> address space held by an LIR in the RIPE NCC Service > Region. This > > >> showed that on average, LIRs would qualify for an additional > > >> allocation block when they have assigned or sub-allocated > > about 59% > > >> of their allocated address space. > > >> > > >> c.Arguments supporting the proposal. > > >> This proposal fairly takes into account addressing > > hierarchies used > > >> in large and extra-large registries and introduces a > > useful level of > > >> flexibility for those registries > > >> The local Internet registries using the 80% criteria may > > continue to > > >> do so and will not be impacted by the new policy. > > >> The RIPE NCC will provide support to minimise complicated > > >> calculations or administrative burden to LIRs. > > >> > > >> d. Arguments opposing the proposal. > > >> This proposal will have some limited impact on IPV4 > > address consumption. > > >> > > >> > > >> > > >> > > >> Appendix A. The HD ratio > > >> > > >> The HD ratio is calculated as follows [RFC 3194]: > > >> > > >> HD = log(U)/log(S) > > >> > > >> Where: > > >> > > >> S is the size of the address block concerned, and > > U is > > >> the number of addresses used. > > >> > > >> Note: The current IPv4 policy considers addresses to be > > 'used' once > > >> they are assigned or sub-allocated by the LIR. > > >> Appendix B. Selection of HD ratio value > > >> > > >> We should decide an appropriate HD ratio value on a > > rational basis. > > >> To do this, we make certain assumptions about the number > > of "hidden" > > >> hierarchical levels involved in managing address blocks > of various > > >> sizes. If we assume there is 80% usage at each level, we > > can easily > > >> calculate the overall usage. > > >> > > >> The following table proposes a set of hierarchical > levels which we > > >> can reasonably expect within different amounts of address > > space. If a > > >> usage of 80% is achieved at each hierarchical level, then > > the overall > > >> usage will be (0.80 to the power of "n"). It is then possible to > > >> calculate HD ratio values from this value. > > >> > > >> Size range Level Utilisation HD ratio > > >> (prefix) (n) (0.80**n) > (calculated) > > >> /24 to /20 1 80% > > .960 to .973 > > >> /20 to /16 1.5 72% > > .961 to .970 > > >> /16 to /12 2 64% > > .960 to .968 > > >> /12 to /8 2.5 57.2% > > .960 to .966 > > >> /8 to /4 3 51.20% > > .960 to .966 > > >> The levels of hierarchy listed above are based on > assumptions > > >> about the likely size and structure of LIRs holding > > address blocks of > > >> these sizes. A reasonable HD ratio value may be 0.96 (a > > round figure > > >> which occurs within most of these ranges) from the table > > above. The > > >> following table gives the usage requirements for IPv4 > > address blocks > > >> from /24 to /8 for this value. > > >> > > >> IPv4 Addresses Addresses > > Util% > > >> prefix total used > > >> 24 256 > > 205 > > >> 80.11% > > >> 23 512 399 > > 77.92% > > >> 22 1024 776 > > 75.79% > > >> 21 2048 1510 > > 73.71% > > >> 20 4096 2937 > > 71.70% > > >> 19 8192 5713 > > 69.74% > > >> 18 16384 11113 > > 67.83% > > >> 17 32768 21619 > > 65.98% > > >> 16 65536 42055 > > 64.17% > > >> 15 131072 81811 > > 62.42% > > >> 14 262144 159147 > > 60.71% > > >> 13 524288 309590 > > 59.05% > > >> 12 1048576 602249 > > 57.43% > > >> 11 2097152 1171560 > > 55.86% > > >> 10 4194304 2279048 > > 54.34% > > >> 9 8388608 4433455 > > 52.85% > > >> 8 16777216 8624444 > > 51.41% > > >> > > >> Note: This table provides values for CIDR blocks, but the same > > >> calculations can be made for non-CIDR blocks. > > >> > > >> As an example, an LIR holding a total amount of address > > space equal > > >> to a /16 would be able to receive more address space > when they had > > >> sub-allocated or assigned 64.17% of that space; while an > > LIR holding > > >> a /9 would be able to receive more space when they had > > sub-allocated > > >> or assigned 52.85% of their address space. > > >> > > >> Appendix C. References > > >> [RFC 3194] "The Host-Density ratio for address assignment > > efficiency: An > > >> update on the H ratio", A. Durand, C.Huitema, November 2001. > > >> [ipv6-address-policy] RIPE NCC document: "IPv6 Address > > Allocation and > > >> Assignment Policy" > > http://www.ripe.net/ripe/docs/ipv6policy.html > > >> [ipv4-address-policy] RIPE NCC document: "IPv4 Address > > Allocation and > > >> Assignment Policies for the RIPE NCC Service Region" > > >> http://www.ripe.net/ripe/docs/ipv4-policies.html > > >> > > >> > > >> > > > > >

1 0

Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site
by Hans Petter Holen 13 Jul '05

13 Jul '05

Dear Address Policy WG, Please find enclosed a policy proposal from Eric Schmidt. This proposal is entered into the discussion phase with a deadline of 4 weeks - August 10th. Best Regards, Hans Petter Holen AC Chair 1.Number: #Eta 2.Policy Proposal Name: IPv6 Address Allocation and Assignment Policy - definition for "End-Site" 3.Author a.name: Eric Schmidt b.e-mail: erics(a)t-com.net c.telephone: ++49 441 234 4592 d.organisation: Deutsche Telekom AG 4.Proposal Version: 5.Submission Date: 2005-05-13 6.Suggested WG for discussion and publication: address-policy-wg or ipv6-wg 7.Proposal type: modify a.new, modify, or delete. 8.Policy term: permanent a.temporary, permanent, or renewable. 9.Summary of proposal There are various terms for "end-site" in the IPv6 allocation and assignment policy (ripe-267) and the RFC3177. We need to have a finally definition for "end-site" to establish clear internal assignment policies 10. Policy text a.Current (if modify): 2.9. End Site An End Site is defined as an End User (subscriber) who has a business relationship with a service provider that involves: that service provider assigning address space to the End User that service provider providing transit service for the End User to other sites that service provider carrying the End User's traffic that service provider advertising an aggregate prefix route that contains the End User's assignment b.New: 2.9 End Site End-Site defines a customer´s network with an own link to the ISP. The customer could run various networks on different locations (e.g. multiple branches). As long as the networks are all independent and have no internal connection, each network is defined as a single end-site. If the networks have internal connection and only one common link to the ISP, these networks are summarized to one end-site. 2.9a A customer is an End User (subscriber) who has a business relationship with a service provider that involves: that service provider assigning address space to the End User that service provider providing transit service for the End User to other sites that service provider carrying the End User's traffic that service provider advertising an aggregate prefix route that contains the End User's assignment 11. Rationale: a.Arguments supporting the proposal At last we will have a concrete definition for end-site. There are a lot of discussions even in different RIR regions and as far as i know non of this has reached an conclusion. The rfc3177 defines end site as single edge networks, this is pretty close to my proposal and i think it is easier to update a RIPE policy than an rfc. This question was discussed in the IPv6 maillist before and it looks like that this definition could get a majority approval In the IPv6 End User Site Assignment Request Form (ripe-308) the requester has to confirm that he read the policy document. It is hard for a customer to understand these improper terms. This proposal should not be combined with the /48 /56 discussion which is on at the moment. It´s just a matter of definition b.Arguments opposing the proposal i can´t see anything against this .....

8 12