We are so not in charge. Support for IPSEC is a requirement to describe an implementation as IPv6. That is all, it does not mean anyone has to use it, or that they will use it. There are two typical modes of deployment for IPSEC, the first is as a lousy remote access protocol where the lack of NAT support makes it far more effort than other solutions. SSL and SSH remote access just works, IPSEC VPN may or may not work depending on the phase of the moon. The third party clients are terrible, the built in support in the O/S is unusable because it does not have the tweaks necessary to get through the firewall. So we do not really have a standard for IPSEC remote access. The other mode for IPSEC is not really an Internet application, it is creating a virtual network by joining together a bunch of routers at local sites. Here the NAT issue is moot because the objective is to create a single network with a consistent IP address space. The fact that this is usually NAT space is not really relevant unless you are attempting to create an industry wide network. Have fun with that. What IPSEC has never got close to achieving is providing an Internet security solution in which packets are secure at the transport layer by default. The obvious reason for this is that IPSEC is not connected to a pervasively deployed PKI for authenticating the end points. There is no commercial infrastructure to support this today, and I doubt that there will be one for some time. NAT is relevant to this scenario only insofar as it will be aa fait acompli long before any PKI is established that might support pervasive IPSEC. And lest folk think I am picking on them here, the reason I raise problems is because I want to see them fixed, not just to carp. I want to deploy DNSSEC because I think that it is the most appropriate PKI to support packet level security. I use NAT for a very simple reason: I do not want my machines to be on the Internet by default. I only want my printers to be accessed by machines in my network. I only want the security system, the home automation system, the daleks, the lab, the coffee maker to be accessible from the network. I do not want Mr Coffee talking to strange computers, he has little common sense. Now I would like my network to have a greater geographic extent than just my house. But there is still a very clear distinction between machines that I own, that I am responsible for, that I want to connect to my network core and all the rest of the stuff on the Internet. Some computers, the desktops and laptops, I do want to have greater access, but there are only eight of them in total, that is a small fraction of my network. The ability to give these devices and IP address THAT WILL NOT ROUTE is very valuable to me as a security control. It is not a perfect control, but I have many, many layers to my defense in depth and I want all of them. We are not in charge of the Internet, but I am in charge of my network, and my policy is to use NAT. In a commercial environment, policy is everything. You do not get security from security technology, you get it from the security practices that the technology supports. Changing a security policy in a commercial environment is a very expensive affair. People are going to demand NAT66 (and cisco is going to support it) because it is cheaper to deploy NAT66 than change the policy. But even then, we are getting way ahead of ourselves. In the real world every network is going to have IPv4 devices on it for decades. I have a 36" plotter upstairs that is ten years old. I am not paying $3K to upgrade it just for the sake of IPv6. On Sat, Nov 7, 2009 at 9:30 PM, Christian Vogt <christian.vogt@xxxxxxxxxxxx> wrote: > > On Nov 7, 2009, Masataka Ohta wrote: > >> I'm not talking about the amount of value to be offset but the >> location of transport checksum. >> >> The location of transport checksum can be known only by traversing >> all the extension headers from the beginning of a (unfragmented) >> packet. >> >> So, the second and latter fragments of the packet may or may not >> contain transport checksum to be offset, which means IPv6 NAT must >> first reassemble fragmentation. > > Why would an IPv6 NAT need to find the checksum if the checksum does > not need to be changed anyway? > >> IPv6 specification requires IPSEC, which means outer most IPv6 must >> also support IPSEC. > > Sure, no one is arguing with this. My point was that, while IPv6 NAT > does interfere with some modes of IPsec, there are other IPsec modes > that are not affected by IPv6 NAT. Makes sense? > > - Christian > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf