Subject: Re: Death of the Internet - details at 11

From: Masataka Ohta <[email-masked]>
Date: Mon, 02 Feb 2004 12:41:26 +0900

Ayyasamy, Senthilkumar (UMKC-Student);

To summarise, read:

	http://www.ietf.org/internet-drafts/draft-ohta-multi6-8plus8-00.txt

which describes a end2end scalable 8+8 id/loc proposal, a lot different
from Mike O'dell's version of 8+8.

>>Also, since the transport is maintaining per path information, it is in
>>the best decision to decide which path to use. 
 
> *nod*.

Correctly speaking, the transport or the application layer
is the only place to decide which pasth to use, since the
IP layer can not maintain timeout.

Attempt to imitate it by IP layer results in NAT, where connection
will be terminated if there is no packets flow for a timeout period
incorrectly guessed by the IP layer. At the upper layers, it is
often perfectly leagal if there is no traffic for 1 hour over
a live connection. But, NAT behaves badly for such connections.

> It is the main reason why multi addressing is the only 
> architectural possibility to do a scalable MH. The problem with
> the remaining solutions (at shim/new identity/network layer) is 
> that they hide the redundancy factor (multiple address -MA) from
> the users. Given the current state (failures, misconfigurations
> and rate limitations,) e2e check (by measurements) is the only 
> option to check path availability. The MA feature gives user a 
> chance to make a choice based on e2e reachability checks. 

Right.
 
> I dont know why people get suprised by explicit announcement of 
> MA. we have been doing this kind of explicit announcement both 
> in DNS ( multiple NX records) and SMTP ( multiple MX records.) 
> So, in a way SMTP reliability is due to explicit announcement of 
> multiple MX records.

That is an argument I made several years ago.

> id/loc split proposals are cool. But, without modifying the routing
> architecture, they can never provide a e2e reliability or explicit 
> user control feature.

Wrong.

8+8 addressing (ID locator separation) works just fine to support
multiple addresses of a host. Note that Mike O'dell made a poor
proposal of an 8+8 variant does not mean others does not work.

With 8+8 addressing, IP layer needs no modification and routing
architecture works as is.

With 8+8 addressing, all the addresses are passed to the upper
layers and controlled there.

Because IPv6 addressing space was designed to leave a group bit
of 8 byte MAC for 8+8 addressing, transport layers, including TCP,
can check the bit to see whethere a host support end to end
multihoming.

That is, API of TCP with 8+8 addressing needs no modificaiton
and the existing code, including Mozilla, works as is without
even a line of modificaiton.

> OTOH, I don't forsee any routing change at 
> *architectural* level in the near future.

> It is time to think 
> on why id/loc split proposals without routing architecture change 
> kill the e2e control/reliability options and are architecturally 
> incomplete.

There has been a lot of 8+8 id/loc split proposal, most of
which does not change routing architecture.

It is granted that Mike O'dell's GSE was a poor id/loc proposal.

But, it is a problem of GSE, not 8+8 nor id/loc separation.

> So, it is clear that a combination/subset of host-centric MH, 
> transport MA and BGP MH (if there exists a solution which 
> doesn't bloat routing table) is the ONLY possibility to do a 
> scalable MHv6.

Read:

	http://www.ietf.org/internet-drafts/draft-ohta-multi6-8plus8-00.txt

though it does not use BGP in a way you might be thinking, which
is why it does not bloat the routing table.

							Masataka Ohta

---

From: RB Jón Eggert Guðmundsson <[email-masked]>
Date: Mon, 9 Feb 2004 09:55:49 -0000

The deployment of ipv6 will be 20-40 years from now. If we do not take possible brakethrough in nanotechnology into account then this is the timeframe we are looking at. See this reference:
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-IPv4-lifetime.pdf
Regards
Jon gudmundsson

-----Original Message-----
From: Noel Chiappa [mailto:[email-masked]] 
Sent: 12. janúar 2004 20:49
To: [email-masked]
Cc: [email-masked]
Subject: Re: Death of the Internet - details at 11

    > From: "Tony Hain" <[email-masked]>

    > Like it or not, the IETF must stop wasting time and effort building new
    > structures on a crumbling framework. 

I agree completely.

Now, can we all agree that almost 10 years after it was formally adopted by
the IETF, IPv6 is has clearly not succeeded in becoming the ubiquitous
replacement for IPv4, and needs to be moved to "Historic", so we can turn our
energy and attention to things that *will* succeed?

	Noel