> Tried getting a /24 lately, nevermind a /22? Or is our future NAT, > all the way down?
There are some discussions if/why NAT will be required for IPv6 as well, so an IPv6 without NAT is not a certainty. Besides the solution for both IPv4 and IPv6 may well lay elsewhere, such as with HIP. http://ietfreport.isoc.org/all-ids/draft-ietf-hip-nat-traversal-09.txt Or tunneling of some type. But not to deflect any more from the multicast vs. p2p discussions, except to point out that IPv6 may not be the answer to the "vs." issue. Certain today is only this: An endpoint app developer has p2p application layer multicast under his/her complete control and various options for NAT traversal as well. No dependency on what may or may not be deployed, when and where by what organizations, authorities, etc. Which is what this list is all about I believe: P2P apps under control of developers. Henry On 2/25/10 8:31 AM, "Eugen Leitl" <eu...@leitl.org> wrote: > On Wed, Feb 24, 2010 at 09:54:31PM -0800, Matthew Kaufman wrote: >> The real problem is that many people still believe the old "IPv6 >> hype"... that IPv6 would bring us automatic address configuration > > Tried getting a /24 lately, nevermind a /22? Or is our future NAT, > all the way down? > >> (solved even more completely by DHCP for IPv4), security (through IPSEC, >> which works just as well in IPv4), multicast (which won't be happening > > Not part of the spec. Especially, opportunistic encryption. > >> in IPv6 either, for most of the same reasons), etc. >> >> Everything that was important enough to get done before IPv6 was fully >> deployed has already happened, and everything that wasn't, won't. >> Nothing magic is coming. >> >> Not even flow labels... which don't really help for the same reason that >> core routers can't do flow caching for IPv4. _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
