Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou...

From: [email-masked]
Date: Wed, 29 Nov 2006 02:56:01 EST

You are right. I only wanted to be cautious. 
Nowadays i.e. in Ebay-times I can observe every now and then a different  
postal service car curving around: Deutsche Post, DHL, UPS, Hermes,...They all  
manage to deliver without a primary postal service provider written on the  
envelopes and packages.
 
I like this more ambitious goal "without primary ISP's ASN".
 
Heiner

In einer eMail vom 29.11.2006 04:06:02 Westeuropäische Normalzeit schreibt  
[email-masked]:

Heiner,

On Nov 28, 2006, at 2:47 PM, [email-masked]  wrote:
> Therefore, I am still in favor of integrating at least  the  primary  
> ISP's ASN as well.

What happens when  you change the 'primary ISP", keeping in mind that  
the current  socket APIs result in applications caching the "address"  
within the  running application itself (struct sockaddr) and people  
need to  transcribe "addresses" into firewall, DNS, and other  services?

Rgds,
-drc

_______________________________________________
Architecture-discuss  mailing  list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Jefsey_Morfin <[email-masked]>
Date: Wed, 29 Nov 2006 16:26:30 +0100

I made a quick search on IPv8 in Google to refresh my memory. It 
seems not very far from all what is discussed here. It is interesting 
because it means that if we do not have other solution, NATs could 
easily update to IPv8 (I understand some code already exists by 
several sources, or equivalent approaches) and find a grassroots 
solution outside of the IETF.

The natural cost increase of IPv4 addresses as they become scarce 
will probably free enough IPv4 addresses so every NAT can have an 
IPv4 address whatever their number (we can already do it). This will 
naturally lead people to divide the cost of an IPv4 address among 
thousands of "second level" IPv8 adresses (more than with NATs). The 
interest is that I do not think there is a big problem to encapsulate 
IPv6 addresses into such IPv8 so there would be a compatibility with 
IPv6 existing deployments.

I suppose that DNS could be progressively adapt and destination NAT 
resolvers will be developped: the IPv4 first level of the IPv8 
address (which is actually the topology, routing part of the address) 
would resolve the domain names even in non IPv8 updated nameservers, 
and the IPv8  second level which is the identification of the user 
and its further levels for exensions could be supported à la NAT, à 
la HTTP.1.1 or à la IPv8.

Some progressive reorganisation of the IPv4 blocks under the price 
pressure could permit RIRs to simplify the routing issues in 
reorganising the addressing along with the main topology organisation.

It is a good thing to know the solution the market would most 
probably adopt, under natural cost considerations, should this debate 
lead to no solution or to a solution with delays comparable to the 
IPv6 deployement. May be could we run some simulation, and spend some 
thinking on that probable grasssroots plan B. Also, on the way it 
could then migrate from IPv8 to IPv6 and prepare accordingly. The 
interest of IPv8 is that it leaves free the user part of the address: 
it permits an understanding diversity.

Another interesting possibility is to remove the actual domain name 
from the packet and to restore it at the "NAT", adressing the problem 
of long punny code sequence, lack of Unicode support, new language 
TLD (DNAME or NS). The IPv8 second level could be the numeric ID of 
the domain name label (permitting to support a variety of services, 
including linguistic TLDs without new root entries). China having a 
large deployment of NATs has certainly considered the possibility 
already. May be IPv10 was not an hoax, but an IPv8+?

May be interesting to consider an IETF/WG-INTERNAT(ional)?
jfc