Shim6 is very different from LISP. Shim6 is implemented in the host, and LISP in the CPE router (like, for example, NAT66 would be). Shim6 seems to have more in common to ILNP than LISP. So your point below doesn't make much sense to me.
-Darrel On May 3, 2010, at 11:54 AM, Fred Baker wrote: > There is one additional comment I should make and overlooked. Folks like > Keith and Brian will point to shim6, the notion that PA prefixes allocated to > edge networks by each of their ISPs, can be used to provide a PA view of the > world to the ISPs. Yes, and notice how great the uptake is. In short, that > (like LISP) moves the complexity of the network to those least motivated and > least equipped to manage it. If you buy RFC 3439's "Principle of Simplicity", > the network has to be simple in all of its places, not just the ones of > interest to you. Moving the complexity to the part time IT manager is not a > recipe for success. So no, I don't see shim6 as a solution. > > I see two solutions that work: exchange-based addressing (what has been > called Metropolitan Addressing) and GSE or some variant of it. Network Prefix > Translation at the IP layer, with application use of names in preference to > addresses, to my small mind produces the simplest of all networks, and comes > most closely to meeting the combined list of goals. > > On May 3, 2010, at 11:21 AM, Fred Baker wrote: >> On May 3, 2010, at 10:25 AM, Chris Engel wrote: >>> On the network level, I basicaly want something that entirely abstracts my >>> internal architecture from my external advertisement of services...and >>> essentialy functions as a proxy/intermediary between my internal devices >>> and thier external presence at the boundary between internal/external. NAT >>> very handly does that currently in IPv4. From the discussions that I've had >>> with alot of people involved with IPv6...and many of the people who have >>> strongly argued against any sort of NAT in IPv6... they basicaly seem to be >>> disagreeing not just with the particular method I want to use....but with >>> my end goal itself. >> >> I would agree that many in the IPv6 community disagree with your goal. Their >> fundamental objective is end to end transparency, and your fundamental >> objective is end to end opaqueness. You disagree with each other. I >> understood from your previous emails in this thread that you felt they were >> "wrong" or that you felt that they felt you were "wrong"; I don't think >> either is "wrong" per se, but you certainly disagree. >> >> Personally, I think the term "NAT" in the moniker for this draft was >> particularly unfortunate, and said that to Margaret when I agreed to >> co-author. Since we are talking about something fundamentally different than >> IPv4/IPv4 NAT, we have the same issue that has been discussed with the term >> "realm". We wind up with this discussion, which is not a stupid discussion, >> but is off topic with respect to the proposal in question. When the IETF had >> a BOF on the topic, that was incredibly clear. We had a proposal on the >> table which was most decidedly *not* re-implementing IPv4/IPv4 NAT in an >> IPv6/IPv6 world, but the entire discussion from the floor was "we don't want >> to re-implement IPv4/IPv4 NAT in an IPv6/IPv6 world", largely non-responsive >> to the topic at hand. It winds up consuming a lot of cycles, is very >> emotional, and drowns out reasonable discussion on anything else. Take a >> look at this thread as an example. We have collectively exchanged 39 >> messages (this is the 40th), of w h > ic >> h perhaps half a dozen have been on topic and the remainder have been >> related to re-implementing IPv4/IPv4 NAT in an IPv6/IPv6 world, something >> which is specifically not the topic of the list. >> >> Regarding NAT, though, in http://www.ietf.org/rfc/rfc4864.txt, some strong >> proponents of the transparent model addressed what they thought were the >> primary reasons for the use of NAT. They didn't cover this one, so to speak. >> But it might be worth your while to acquaint yourself with their viewpoint. >> In short, NATs not only achieve a certain level of obfuscation of the >> network layer, they make it harder to build applications of a certain class >> - applications in which the address of one's peer must be known at the time >> one wants to use it. Real time applications, such as VoIP and Video/IP, fall >> in this category. More generally, the entire realm of peer-to-peer >> applications does. The imposition of NAT has not altogether stopped such >> development, though; what it has done is make it a lot harder, resulting in >> companies like Napster, BitTorrent, and Skype building byzantine overlay >> networks to overcome the issues it presents. In the realm of voice and >> video, it has engendered RS I > P >> and the use of SIP Proxies as gateways between domains. NAT hasn't actually >> protected any networks, I will argue; it has merely made scaling the walls a >> little harder. >> >> The goal of those that would like to not have any translation at all - here, >> Keith, I'm putting words into your mouth, so please feel free to correct >> them - is essentially the counterpoint of that. The world is poorer for the >> applications that have not been developed due to firewall and NAT >> boundaries, and they would like to be able to build interesting applications >> that don't need the byzantine structures to bypass what they consider to be >> ineffective and deluded security architectures. If using NAT to flatten the >> addresses expressed at the DMZ has been ineffective in preventing attacks >> (the vast majority of which come from behind the firewall anyhow) and have >> made application development more difficult, what's the point? They would >> rather go with the end to end principle as stated by Saltzer >> (http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf) and >> enable users to make the Internet and the applications that use it more >> valuable. >> >> For my part, and the part of this proposal (and the ILNP proposal that RRG >> is putting forward), I am all for the free development of useful >> applications. I don't see the value of NAT, given its history of not >> stopping attacks and of preventing applications. I see a problem that needs >> addressing though, related to management of the backbone route table. In >> short, we now have O(10^5) prefixes in the IPv4 route table, and perhaps two >> years from now will easily have O(10^6) as people buy and sell prefixes. As >> an equipment vendor, I have no problem with that - if you'll pay for the >> memory, I'll happily sell it to you. But I don't want to hear about either >> capex or opex, I don't want to hear about "green" aspirations, and I don't >> want to hear about the price of the equipment. You make the bed, you lie in >> it. As we collectively move to IPv6, we have a choice. We can replicate the >> IPv4 swamp, complete with its route table, or we can change it. I vote that >> we change it. >> >> In the area of addressing, networks at the edge are pushing back very hard >> on the provider-allocated addressing model, and are driving for >> provider-independent addressing. Reason: they don't want to be captives of >> their providers. I'm sympathetic with them. But consider the implications: >> if they all have PI addresses, we are enumerating the objects at the edge, >> and even today we have O(10^7) or more objects at the edge. PI addresses >> take us in the direction of a swamp at least as bad as that in the IPv4 >> network. Service providers find the PA model very attractive, both because >> it provides a market lock on their customers and because it helps them >> manage their route tables. >> >> From my perspective, I would like to achieve some of the goals of all of the >> players. I obviously can't both lock and unlock customers, so whatever I do >> is wrong there from someone's perspective. But by Network Prefix >> Translation, the subject of this list, I can give edge networks the >> appearance of PI (they are independent of their providers for addressing) >> and the service providers the appearance of PA (they enumerate the ISPs at >> the edge, O(10^3 to 10^4) instead of objects at the edge, O(10^5, 10^6, or >> 10^7)). The boundaries are address-translucent, not either transparent or >> opaque, so while I don't give you what you want I give you something a step >> in its direction. And I give Keith what he wants - if he can find it in his >> heart to have applications use names instead of addresses, he gets all of >> the access between applications that he needs. And for those that operate >> networks, it reduces their capex and opex. It requires everyone to think a >> little differently, but if t h > ey >> are willing, they get most of what they are looking for. >> >> I hope this is useful. >> _______________________________________________ >> nat66 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nat66 > > http://www.ipinc.net/IPv4.GIF > > _______________________________________________ > nat66 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nat66 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
