Scott Leibrand wrote: > Jeroen Massar wrote: > >> The above hosts are Internet connected and most likely will thus also >> end up >> talking to the Internet at one point or another. I can thus only guess >> that >> they will be wanting to fully connect to the Internet one day and the >> generic solution to that problem is NAT. We wanted to get rid of NAT for >> IPv6. If NAT is again being done for IPv6 then we can just as well >> give up >> and just keep on using IPv4 as there really is not a single advantage >> then >> anymore to IPv6. >> >> > I think what we wanted to get rid of in IPv6 was one-to-many NAT, also > know as PAT (among other names). In IPv6, we can stick to one-to-one > NAT, which eliminates most of the nastiness we associate with NAT in > today's IPv4 world.
No it does not eliminate anything, it still requires Layer 4+ rewriting of addresses, and that is the nasty bit. Also NAT breaks this cool "new" (ahem) feature called IPSEC, which when deployed, would also make deep packet inspection impossible. The latter requiring one to look inside packets too, but not rewriting them. [..] >> The big thing there is though: configure your firewalls correctly as the >> public addresses do also allow access to everything. >> > I don't think routers are at the point yet where you can easily renumber > your routers' interfaces when your PA addresses change. As a result, > networks wanting to avoid the pain of renumbering, but who don't qualify > for PI and a global routing slot, might want to do something similar: DHCP-PD, which can work in most small networks. I am not discussing anything that has more than say 20 boxes in such a network though but: small network. > Say a network gets a ULA-C block, and numbers everything on their > network out of that block. They later connect to the Internet, Your example is already failing. When they want to connect to the Internet somewhere, it is MUCH easier for them to just get a PI block, then they can always use that even with or without BGP. And maybe one day with a nice id/loc solution when that comes out. > and get > a PA block from their upstream, and configure it on their border > routers. To avoid reconfiguring all their routers every time they > change upstreams, they configure one-to-one NAT on their border routers, > such that every address on their internal network (which is ULA-C) maps > to the same address, except with different first 48 bits, in their > provider-allocated block. This can perfectly be done with PI blocks in exactly the same way. The advantage here is though that one day the PI block might be used globally, while the ULA-C one can never be used in that way. > This wouldn't present the same kinds of problems you'd get from > one-to-many NAT, but I'm sure there are some ways where this wouldn't be > as good as PI space. However, my first-order evaluation is that it > would be better to have small networks achieve their provider > independence this way, rather than by relaxing the PI rules and > threatening the scalability of the current routing system with a large > number of additional non-aggregatable netblocks. The ARIN PI rules are already very relaxed: cough up $100 US yearly and presto you have a fine /48 IPv6 PI. > Now as expressed earlier, most ULA-C use cases probably won't involve > NAT. But if people do elect to use NAT with ULA-C, what problems do you > see with this kind of use of NAT? Do you see those problems as worse > than the problems caused by completely rejecting the original PA-only > architecture of IPv6 in favor of PI-for-everyone? The big problem with NAT that I have as a programmer is that I will have to make my protocol & program understand NATs and use them. I don't want to care about them, there is End-To-End. With a NAT what happens is that the NAT device will have to understand every protocol out there. Thus I come up with a new protocol which is really cool, and first I have to convince everybody on the planet to update their NAT boxes to support that protocol. That is not going to work, and as such people will write protocols which have to evade those NAT boxes and are thus more complex and more error prone and less versatile. >> Still, the above can also be accomplished perfectly fine with PI space >> and >> that doesn't require any changes (except RIPE+APNIC policy) to be done. >> >> > I agree that PI space, if it were widely available, would meet the same > needs as ULA-C. However, I think we need to be realistic that > PI-for-everyone won't fly, and need to think creatively about ways to > achieve the same goals (such as provider independence) in such a way > that we don't impose more public cost than private benefit. Why would ULA-C fly and PI not? They can be used in exactly the same way with a huge advantage for the global unicast variant that it can at one point also be used in BGP and other variants. Having PI doesn't mean that one is going to announce that to the global Internet, you can still use it on your local network without ever hooking up to that beast, but when you want to you can. For all those ISP's who are 'afraid' of getting a zillion customers who want to do PI: Well raise the prices. Isn't that how it works? If you have something people want: make it more expensive and make more money of it so that you can buy new gear and do other such investments. Why are people afraid of doing business? At a certain point getting a PI block from a RIR might be cheap, but actually routing it will be expensive, that solves the problem of too many routing slots doesn't it? But does that depend on the type of address space: no. > Another thing to consider when evaluating whether to specify something > like ULA-C is that we can't know what kind of innovation it will make > possible in the future. At least I can tell you what kind of innovation it will stop, see above: all new protocols not supported by your ALG. > Therefore, the question we should be asking is, > is there any remaining reason *not* to allow networks to register ULA-C > space? The question still is: is there any REAL application of ULA-C which can't be solved with a normal global unicast prefix? > When it was last proposed there was: it was thought that > networks would get ULA-C and use it as PI space. Now, since PI space is > readily available to multihomed networks, that is much less likely. The problem here is not that it is less likely, the problem is that businesses will get ULA-C space and think that it is PI and still will want to use it as PI. > As > a result, I am in favor of allowing small networks to register their own > unique private space, as this draft would do. Let them get a nice PI block from a RIR if that is what they need. > I can't predict how ULA-C will be used If you can't come up with an actual use case for it yourself, then why promote it? Especially in the light of the counter arguments given? > but I'm confident that innovation is a good thing Which innovation could lead from this? IPv6 NAT is *not* an innovation, it is repeating the same mistake as IPv4 had: no end to end. > and that we can safely open up the ULA-C sandbox to networks who wish to use > it. Add water to that sandbox and dilute, what you mean is "open up the swamp". How safe is that? People will expect it to work, and it won't work, thus that is not 'safe'. I do have to note one minor thing about NAT: when done in two ways, thus that the sender NATs to a global address and the receiver NATs back to the original address, no problem exists, but that is in effect a tunnel, and that is in effect also what the various current id/loc proposals are looking at in one way or another. Greets, Jeroen
signature.asc
Description: OpenPGP digital signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
