Hi, Is there anyone experienced in creating RIPE policy documents AND ready to help me to create a new one? (Or: two new ones). In the previous RIPE meeting I gave a talk ( http://www.ripe.net/ripe/meetings/ripe-55/presentations/turchanyi-two-jokes-...) and attached a copy of a draft-RFC ( http://www.ripe.net/ripe/meetings/ripe-55/presentations/turchanyi--two-jokes... ) I realized that some of my ideas relate to policies, other relate to technologies. As there is a separate policy working group now, I try to create a policy document as well – and need some help to formalize and may be finalize, correct my ideas. Highlights: 1, AS-local IPv4 address pool creation and maintenance 2, IPv6 address pool and address allocation for dummies Details1 (AS-local IPv4): The drafts ( http://www.ripe.net/ripe/meetings/ripe-55/presentations/turchanyi--two-jokes...) gives more details, please find a short summary below. One of our responses to IPv4 address scarcity was the creation of "IPv4 private address pool" in 1994-1996. However: The scope of private addresses is not defined well; The private address pool size is too small for large ISPs; Network Address Translation should be in use at every routing domain borders. AS-local IPv4 pool should be similar but a little bit different compared to private address pool: Uniquely use in every Autonomous system (or collaborative group of ASs) Different set of IPv4 addresses (different scope!); Mechanism to add and revoke address-blocks by contributors to this pool should be implemented (in order to create a contribution-friendly atmosphere); Network Address Translation should be applied only if the destination address is outside of the originator Autonomous System boundary. The introduction of AS-local addresses would help us not only maintain our present IPv4 service, however, support the IPv4->IPv6 transition. (See below) Details2 - IPv6 address pool and address allocation for dummies: As everybody knows, there are well defined IP address allocation policies for fixed, static networks, like an University campus, or an enterprise network. These sites should have administrative and technical contact persons, the "tech" knows what an IP address is, the "admin" pays the bill, and both person is in the database of the Regional Registry. However, a huge part of the IP address space is used differently: both the "tech" and the "admin" work for the ISP, and the actual costumer of the IP address might not even know that he/she is using an IP address. (is a dummy costumer, only in this respect). This is the typical case in DSL environment today with IPv4. The introduction of IPv6 won't change too much. Shall we treat and regulate the IP address allocation for the "dummies" in the same way as we do it for the "experts"? I do not think so. In fact, we can not. Is there any policy for the "dummies"? I was unable to find it. If you have 30 millions "dummy" DSL (or cable modem, or mobile-phone) users how would you provide IP addresses for them? Of course, global addresses are the best. However, as there are not enough global addresses, some tricks should be applied. Common practice: allocate IP addresses dynamically. (BTW: dynamic allocation also mean pseudo-anonym and temporary allocation.) Dynamic allocation saves addresses considerably. However: If only 50% of the costumers connect at peak time today, tomorrow this may increase to 60%. That means: the need for addresses increased 20% while the costumer base is still the same. Using non-global, reusable IP addresses still does not solve all the problems. 30 millions is much more than the total size of the private address pool. Even if the ISP would assume, that not all users connect to the network at the same time, it might not help for long time as the number of costumer being on-line at peak time might increase. AND: using private addresses also means loosing functions. If your computer has a private address, you can not provide any services outside the private address domain (this stops using a couple of popular games, etc) This restriction is unavoidable consequence of using any kind of reusable addresses. However: the private address domain is very restricted. By using AS-local addresses, we would have a larger routing domain and fewer restrictions.) If we create an AS-local address pool, then it is possible to allocate reusable IP addresses in a more stable manner. This allocation is still a dynamic allocation, however, rather stable AND easy to couple IPv6 allocation with it. However, if we allocate IPv6 networks for every costumer that use dynamic IPv4 allocation today then most of them won't use for a while the IPv6 stuff. AND this IPv6 allocation will be pseudo-anonym, not directly reflected in the RIPE (or other RIRs) database. Therefore I suggest that ISP-s should have a dedicated IPv6 address pool for "dynamic IPv6" allocations and these address pool should be easily recognizable. (This was the reason why I proposed in my talk at RIPE 55, that all "dynamic IPv6" pool should be allocated from an IANA dedicated /16 prefix) The size of the "dynamic IPv6" network should be the minimal one: /64. If there are mechanism that allows automatic use a subnet, than a little bit bigger size might be allowed (max /60), however if /56 or /48 would be allowed than there wont be any more interest to have a RIPE registered network instead a "dynamic" one, therefore my suggestion is to declare in the policy that a "dynamic" IPv6 allocation should be as narrow as possible. OK. Please help me to rewrite the above idea to formulate policies. Thanks, Geza Turchanyi INFO-C
On Wed, 30 Apr 2008, Turchanyi Geza wrote:
One of our responses to IPv4 address scarcity was the creation of "IPv4 private address pool" in 1994-1996. However:
The scope of private addresses is not defined well;
The private address pool size is too small for large ISPs;
Network Address Translation should be in use at every routing domain borders.
Why? If one doesn't feel the need to use NAT, why should NAT be mandatory?
AS-local IPv4 pool should be similar but a little bit different compared to private address pool:
Uniquely use in every Autonomous system (or collaborative group of ASs)
What's a collaborative group of AS'es? And what's a non-collaborative group os AS'es?
Different set of IPv4 addresses (different scope!);
Mechanism to add and revoke address-blocks by contributors to this pool should be implemented (in order to create a contribution-friendly atmosphere);
Past experience tells me people who manage address blocks *rarely* feel any urge to give back unused space...
Network Address Translation should be applied only if the destination address is outside of the originator Autonomous System boundary.
The introduction of AS-local addresses would help us not only maintain our present IPv4 service, however, support the IPv4->IPv6 transition. (See below)
I don't agree it would help with v4 to v6 transition. Then AS border routers would have to route between 100.110.120.130-local and 100.110.120.130-internet. Seems kind of odd :-) This is kind of similar to administratively duplicate the v4 internet's space...
Details2 - IPv6 address pool and address allocation for dummies:
As everybody knows, there are well defined IP address allocation policies for fixed, static networks, like an University campus, or an enterprise network. These sites should have administrative and technical contact persons, the "tech" knows what an IP address is, the "admin" pays the bill, and both person is in the database of the Regional Registry.
Unfortunately not everybody knows about it, nor that always happens... :-(
However, a huge part of the IP address space is used differently: both the "tech" and the "admin" work for the ISP, and the actual costumer of the IP address might not even know that he/she is using an IP address. (is a dummy costumer, only in this respect). This is the typical case in DSL environment today with IPv4. The introduction of IPv6 won't change too much.
Allow me to disagree. The main difference with IPv6 is the ability to assign each DSL customer with a set of subnets instead of a unique *temporary* IPv4 address! And while in the v4 world, you don't insert the record for 1 customer/1 IP, you could theoretically do it in the v6 world... (1 customer/ 1 slash-48or56or60or64)
Shall we treat and regulate the IP address allocation for the "dummies" in the same way as we do it for the "experts"?
Not sure if i like the "dummies"/"experts" context. This clearly need rephrasing if a policy proposal goes ahead... :-)
I do not think so. In fact, we can not.
Is there any policy for the "dummies"? I was unable to find it.
If you have 30 millions "dummy" DSL (or cable modem, or mobile-phone) users how would you provide IP addresses for them?
Yes, for everyone of them, but not at the same time. Hence, the "temporary". :-)
Of course, global addresses are the best. However, as there are not enough global addresses, some tricks should be applied.
And they are........
Common practice: allocate IP addresses dynamically. (BTW: dynamic allocation also mean pseudo-anonym and temporary allocation.) Dynamic allocation saves addresses considerably. However:
If only 50% of the costumers connect at peak time today, tomorrow this may increase to 60%. That means: the need for addresses increased 20% while the costumer base is still the same.
Using non-global, reusable IP addresses still does not solve all the problems.
30 millions is much more than the total size of the private address pool. Even if the ISP would assume, that not all users connect to the network at the same time, it might not help for long time as the number of costumer being on-line at peak time might increase.
Question: Have you ever been on a network which had under-provision of IP addresses? I surely did have. And it was kind of annoying. :-)
AND: using private addresses also means loosing functions. If your computer has a private address, you can not provide any services outside the private address domain (this stops using a couple of popular games, etc) This restriction is unavoidable consequence of using any kind of reusable addresses. However: the private address domain is very restricted. By using AS-local addresses, we would have a larger routing domain and fewer restrictions.)
If we create an AS-local address pool, then it is possible to allocate reusable IP addresses in a more stable manner. This allocation is still a dynamic allocation, however, rather stable AND easy to couple IPv6 allocation with it.
However, if we allocate IPv6 networks for every costumer that use dynamic IPv4 allocation today then most of them won't use for a while the IPv6 stuff. AND this IPv6 allocation will be pseudo-anonym, not directly reflected in the RIPE (or other RIRs) database.
That depends on each LIR......
Therefore I suggest that ISP-s should have a dedicated IPv6 address pool for "dynamic IPv6" allocations and these address pool should be easily recognizable. (This was the reason why I proposed in my talk at RIPE 55, that all "dynamic IPv6" pool should be allocated from an IANA dedicated /16 prefix)
In other words, a new «IPv6 very large private addressing» space?
The size of the "dynamic IPv6" network should be the minimal one: /64. If there are mechanism that allows automatic use a subnet, than a little bit bigger size might be allowed (max /60), however if /56 or /48 would be allowed than there wont be any more interest to have a RIPE registered network instead a "dynamic" one, therefore my suggestion is to declare in the policy that a "dynamic" IPv6 allocation should be as narrow as possible.
IPv6 can in fact be the tool to drop the "dynamic" allocation of addresses^H^H^H^H^H^H^H^H addressing inside any ISP network..... so i don't really understand what's the objective here.
OK. Please help me to rewrite the above idea to formulate policies.
Thanks,
Geza Turchanyi
INFO-C
Best Regards, ------------------------------------------------------------------------- Carlos Friac,as See: Wide Area Network Working Group (WAN) www.gigapix.pt FCCN - Fundacao para a Computacao Cientifica Nacional www.ipv6.eu Av. do Brasil, n.101 www.6diss.org 1700-066 Lisboa, Portugal, Europe Tel: +351 218440100 Fax: +351 218472167 www.fccn.pt ------------------------------------------------------------------------- The end is near........ see http://ipv4.potaroo.net "Internet is just routes (241744/992), naming (billions) and... people!" Esta mensagem foi enviada de: / This message was sent from: 2001:690:2080:8004:250:daff:fe3b:2830 Aviso de Confidencialidade Esta mensagem e' exclusivamente destinada ao seu destinatario, podendo conter informacao CONFIDENCIAL, cuja divulgacao esta' expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para o telefone +351 218440100 devendo apagar o seu conteudo de imediato. Warning This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received due to any error, please notify us via e-mail or by telephone +351 218440100 and delete it immediately.
If you have 30 millions "dummy" DSL (or cable modem, or mobile-phone) users how would you provide IP addresses for them
According to current RIPE policy, you assign each one of these DSL or cable modem customers with a /48. Mobile phones are different and should probably get a /64 since their internal networks will not have additional interfaces added. Of course, in the future we will have mobile phones which can act as Internet gateways for our car LAN and then they will get a /48. There are enough /48's availble in IPv6 to give every living human being over 4000 of them, so I don't see any problems with 30 million assignments. As far as education goes, the following ARIN wiki page has a good summary of how to set up an IPv6 allocation plan and it also links to an Internet draft that has a more detailed discussion of the topic: http://www.getipv6.info/index.php/IPv6_Addressing_Plans Everyone involved with IPv6 addressing on a practical level, should read this wiki page and the documents that it references. --Michael Dillon
Michael, You wrote:
If you have 30 millions "dummy" DSL (or cable modem, or mobile-phone) users how would you provide IP addresses for them
According to current RIPE policy, you assign each one of these DSL or cable modem customers with a /48. Mobile phones are different and should probably get a /64 since their internal networks will not have additional interfaces added. Of course, in the future we will have mobile phones which can act as Internet gateways for our car LAN and then they will get a /48.
That's not actually what the current policy document says. It's actual wording is: 5.4.1. Assignment address space size End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site). The old policy (ripe-412) had the reference to RFC 3177 that you have paraphrased. But that recommendation has been removed and the only suggested limit is a minimum value of /64. Apart from that minimum, the network operator can do whatever makes most sense to their network and customer base. So, in answer to the original question, 30m /64s is fine if that's what is needed and 30m /56s is fine if that's what is needed and 30m /48s is fine if that's what is needed. There is a presumption of subsidiarity in the policy text, putting the choice into local hands. Regards, Leo Vegoda
That's not actually what the current policy document says. It's actual wording is:
5.4.1. Assignment address space size
End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site).
Ok, it has changed and I did not notice it. By the way this is TERRIBLE English. Parentheses are no substitute for clear language. The size of the assignment is a local decision for the LIR to make. The minimum value of the assignment is /64 which is to be used when only one subnet is anticipated for the End Site. Of course this leaves out some important context explaining that all ordinary End Sites such as businesses and homes, should be allocated enough for multiple subnets. The overall recommendation globally, from the designers of IPv6, is to allocate a /48 to all End Sites regardless of their size, unless you are CERTAIN that there will NEVER be more than one subnet at the site. So even though RIPE policy leaves it wide open, there is still such a thing as best practice, and there is guidance from other sources. One of those sources is ARIN policy in which they suggest that it is acceptable to assign a /56 to End Sites which are homes or individual apartments. They did this because cable ISPs were concerned that allocating a /48 to every home would be too wasteful. I believe that American cable companies have to allocate IP addresses for every home that is reachable by their cable system even though many customers will use DSL or dialup or wifi Internet access from another company. It would be nice to see an IPv6 addressing best practice document that covers all these areas, whether they are RIR policy, technical or administrative issues.
So, in answer to the original question, 30m /64s is fine if that's what is needed and 30m /56s is fine if that's what is needed and 30m /48s is fine if that's what is needed. There is a presumption of subsidiarity in the policy text, putting the choice into local hands.
Seems to me that the question was not as vague as your answer implies. The writer referred to 30 million DSL, Cable modem or mobile users. If those really are 30m DSL or cable modem users, then /64 is NOT the right answer. /56 is what is needed for homes, and /48 is needed for businesses. There is no advantage to the ISP to ever allocate less than /56, except to very special sites where they are certain that there will never be more than one subnet. For example a fibre amplifier site might get a /64 or a city traffic light control station, or a kiosk on the street. This is an area where more guidance is needed complete with real-world examples to help people understand how it should work. --Michael Dillon
Hi, On Wed, Apr 30, 2008 at 04:05:23PM +0100, michael.dillon@bt.com wrote:
Ok, it has changed and I did not notice it. By the way this is TERRIBLE English. Parentheses are no substitute for clear language.
Unfortunately, too many of us are not english native speakers. So we *do* welcome textual improvements during the policy development process... Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 110584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Ok, it has changed and I did not notice it. By the way this is TERRIBLE English. Parentheses are no substitute for clear language.
Unfortunately, too many of us are not english native speakers. So we *do* welcome textual improvements during the policy development process...
People from Northern European countries often write better English than native speakers do. In any case, the word "English" has too many meanings and is ambiguous. I should have said that this was terrible "grammar" or terrible "wording". It would be the same if the text was written in French or German. --Michael Dillon Ich komme in Berlin an, Sontags Abend. À bientôt!
On 30 apr 2008, at 16:05, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
According to current RIPE policy, you assign each one of these DSL or cable modem customers with a /48. Mobile phones are different and should probably get a /64 since their internal networks will not have additional interfaces added.
That is a misconception. If I want to go online with my laptop through my mobile phone's cellular link, I need a prefix between the laptop and the phone and then something between the phone and the ISP. So that could be two separate /64s or some other setup, but just an address for the phone doesn't cut it.
participants (6)
-
Carlos Friacas -
Gert Doering -
Iljitsch van Beijnum -
Leo Vegoda -
michael.dillon＠bt.com -
Turchanyi Geza