[address-policy-wg] Joking follow-up

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.