Re: [RAM] Renumbering impossibility: TSL/SSL certs, DNS delegation etc.

+1

as I explained many times addresses should be three orthogonal folds 
: fixed, mobile, and virtual. I recently explained that "UP - user 
protected addressing area" was missing in Thomas' review, and that an 
address had to be "AP + IP + UP", each being separately managed. I 
explained many times that an IPv6 addressing /3 block could be 
organised that way, with three different registries and very small 
tables if AP is E.164 related. Also, that as long as there is no 
"plug and play" like standardised possibility protected in the user 
addressing area, users will not be interested in IPv6.

Multilevel addressing obviously offers more possibilities that my 
IPv6 respectful proposition. This includes virtual addressing (and 
multilingual naming) over the solution that will be eventually worked 
out to solve ROAP or the grassroots IPatch that could deploy. The 
bonus would be that such a virtual presentation layer could deploy on 
other technologies as well and permit migrations.

jfc

At 18:27 07/08/2007, Olivier Bonaventure wrote:
>Robin,
>>I am adamant that end-users need portability and portability based
>>multihoming, not some supposedly easy renumbering process and
>>multihoming which automagically renumbers their network.
>
>I think that we strongly need to distinguish between addresses used 
>as locators and addresses used as identifiers. Users will probably 
>want to keep the same identifier, but they don't care about the locators.
>
>Today, most end users received their IP address (which serves as 
>both locator and identifier) through DHCP. They don't need to keep 
>the same IP address always and some ISPs that are charging premium 
>for 'static' IP addresses make sure that DHCP assigned addresses 
>change every few days. End users who are willing to have stable 
>"identifiers" today rely on the DNS, either by coupling the DNS 
>server with the DHCP server or by using services such as dyndns. 
>Endusers don't care about portability of addresses, most of the 
>time, they don't see the IP addresses.
>
>
>Olivier
>
>
>--
>http://inl.info.ucl.ac.be , Universite catholique de Louvain, Belgium
>
>_______________________________________________
>RAM mailing list
>RAM@iab.org
>https://www1.ietf.org/mailman/listinfo/ram

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram