What Fred is talking about here sounds a whole heck of alot like the philosophy behind the OSI model that I was taught some 20 years ago or so..... The idea that higher level applications shouldn't neccesarly dictate choices far lower in the Model. That's a vaulable thing, IMO. Now, I realize that reality is far different in practice then theory...but I think efforts would be better spent improving reporting capabilities of higher level naming schemes rather then mandating lower level protocol choices. Going that route, a guy could be running IPX/SPX and your application (in theory) would still be able to function.
Christopher Engel Network Infrastructure Manager SponsorDirect [email protected] www.SponsorDirect.com p(914) 729-7218 f (914) 729-7201 > -----Original Message----- > From: Fred Baker [mailto:[email protected]] > Sent: Monday, October 25, 2010 12:19 PM > To: Chris Engel > Cc: 'Keith Moore'; Roger Marquis; Wasserman; [email protected]; > [email protected] > Subject: Re: [nat66] Fwd: New Version Notification for > draft-mrw-nat66-00 > > > > On Oct 25, 2010, at 8:42 AM, Chris Engel wrote: > > > Regardless, nothing the authors are doing with this flavor of NAT > > (unless I'm mistaken about it) should break end to end connectivity > > between devices running IPv6 since it's a 1:1 stateless > mapping. A FW > > with statefull inspection and packet filtering rules would...but in > > that case the person deploying the FW WANTS that > connectivity broken. > > If you're trying to argue that people should not be allowed > to deploy > > FW's.... well then, good luck with that. > > Agreed. Not that there are not issues with prefix > translation; there are applications and application > deployments that make the (for the past 15 years > indefensible) assumption that an address carried as a literal > in an application will be meaningful to its peer, and those > applications will have the same RFC 2993 problems that IPv4 > NAT imposes. However, as your say, prefix translation enables > any two interfaces in the network to communicate as long as > the application doesn't depend on that assumption. > > By the way, those applications have problems with IPv4 to > IPv6 transition even without the NAT. Imagine that Alice and > Bob have IPv6 connectivity but not IPv4 connectivity - we > have progressed to a point at which either one of them lacks > an IPv4 address at all or routing between their IPv4 domains > is broken. Imagine Alice connects to Bob to open an http, > sip, or whatever session, and Bob replies with either an > IPv4-literal referral or an image pointer that contains an > IPv4 literal. Alice won't be able to access it. > > So, from my perspective, the time has come to get over it. > Applications should deal in application concepts like DNS > names, and should not impose any coupling to the network > layer. That has to become true with or without NAT for the > transition to occur. Once we have done that, giving the edge > networks independence from their upstream (internally they > can use a ULA or whatever) and the transit networks the > ability to assume that prefixes are PA (there are O(10^4) > networks they care about, not O(10^7) or greater) should be > straightforward. > _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
