On Mar 3, 2011, at 11:53 PM, Xiangsong Cui wrote: > Is the requirement for NAT in IPv6 Internet avoidless?
Well, if you do read the spec, you'll find that the issue it addresses is address independence for the edge network. There are three ways an edge network can get its addresses: it can get a private address of some form and have that translated upstream (some variation on translation), it can get its address from the upstream (PA addressing, the premise behind shim6), or it can get a global address independent of its upstream (PI). > Cann't we (service provider) find appropriate policy or strategies to address > this problem? > Or the Internet situation has changed? Well, I will argue that we indeed have. We have all three of those options on the table, plus what I call "exchange-based multihoming" and Steve Deering in Stockholm 1995 called "Metropolitan Addressing". You might take a look at http://www.ietf.org/rfc/rfc3582.txt 3582 Goals for IPv6 Site-Multihoming Architectures. J. Abley, B. Black, V. Gill. August 2003. (Format: TXT=17045 bytes) (Status: INFORMATIONAL) At IETF-67, in 2006, Vince Fuller and I spoke to v6ops about multihoming, looking at the requirements for multihoming. Vince, who has background with BARRNET, spoke from an operational perspective and used the slides at http://www.ietf.org/proceedings/67/slides/v6ops-13.pdf. His point could be summarized as "GSE: Just do it, let the applications figure out what they're going to do as a result". I started from RFC 3582, and looked at the implications of the various choices. RFC 3582 could be described as "we have PI addressing and we really like the features it gives us, but it has a scaling issue; whatever you do, make sure it works as well as PI addressing". I have had some disputes on some of the evaluations I made re shim6; the folks who like it don't like what I said, and I did make an error on session cutover. But you might want to look at: http://www.ietf.org/proceedings/67/slides/v6ops-4/sld1.htm Having looked at that, look also at http://www.ietf.org/proceedings/73/slides/behave-14.pdf, which is Margaret and my slides from IETF 73 Behave; you may also want to review the minutes of that meeting, and perhaps the other internet draft I posted for context - http://tools.ietf.org/id/draft-baker-v6ops-b2b-private-routing. It repeats some of the same material from IETF 67, but drops exchange-based multihoming and goes into GSE. Let me walk through the possible solutions and the pain points. The one we probably know best is provider-independent addressing, because we talk about it. If I'm a company like Cisco, which has offices around the world, a dozen or more access portals where we communicate with twice that many ISPs as "our service provider", and 100,000 employees, it's pretty easy to describe ourselves as having an "internal ISP" (our IT department), and are a network comparable to a large ISP in our own right. We need our own prefix from a routing perspective and an address management perspective. Globally, that gives us good routing, relatively simple network management, yadda yadda yadda. How does that relate to Jari Arkko's home, which is multihomed (two ISPs)? If we're talking about multihoming for the typical Internet edge network, which is probably a company of 50 people, we're talking about enumerating the edges of the network in our route table - order of 10^7 prefixes in the route table by 2025, per Marshal Eubanks' study for NANOG. That translat es to memory, power, cooling, issues around rerouting on failure or recovery, and so on. By the way, it's what everyone says they want. A variation on PI addressing is what Randy described on v6ops a few days ago: he has several ISPs, derives his prefix from one, and advertises that address space into his other ISPs. From one perspective, that is in fact PA addressing - the prefix was allocated by one of his upstreams. However, to his other ISPs, it is identical to PI - it's not their prefix, they have no way to aggregate it, and if they want to provide him with full service they have to also advertise that to their peers and upstreams. And to top it off, his primary ISP has to advertise the prefix upstream itself, defensively, as otherwise all traffic will go through their competitors. I call that "PA like PI", and treat it as a variation on PI. The outcome is essentially the same - we enumerate the edge, with direct impacts on hardware costs, operational costs, and so on. The other one we know well involves some variation on network address translation. To the transit backbone, we no longer have to enumerate the edges; we are enumerating the points of attachment, dramatically reducing the route table to the size we see today in the IPv4 network and nominally to a prefix for each ISP in the world - on the order of 5,000-10,000 routes. From the user's perspective, as with PI addressing, he doesn't have to think very hard about his upstream's addressing. The issues are in the application: this is Keith's cue to comment. With the kind of thing we have done in IPv4/IPv4 NAT, the vast majority of the edge network is simply incapable of offering services to anyone outside it. With NPTv6, which is prefix translation and is transparent between the inside and outside network apart from the fact of having different addresses inside and outside, systems "inside" can offer services to systems "outside", but it takes some changes in thinking. One that we think we know well but IMHO haven't thought through from the Enterprise perspective adequately is shim6. The premise is that the ISP allocates a prefix to each of its customers, and the customers distribute a /64 to each of its LANs from each of those prefixes. Effect on applications - they see end to end addressing, and just work, and the proposed host changes, if anyone actually implemented them (nobody has to my knowledge), means that you can change the address of a session without thinking too hard. Effect on the transit backbone - wonderful. Effect on the enterprise network administrator - good grief. shim6 is DOA because they simply aren't willing to do it. One that we don't talk about is Steve's Metropolitan Addressing, what I call exchange-based addressing. The premise here is that instead of putting a prefix on an ISP, put a prefix on an address exchange. The reason I don't like the word "Metropolitan" is that it makes it sound geographic or associated with a governmental unit; I'll argue that it is best associated with an Internet Exchange, whoever you choose to run that exchange. Net effect for the access service provider is a larger route table, as he now as a prefix for a /56 or /60 for each customer; in the larger network, it behaves a lot like PA, which is to say order of 10^4 routes. For the customer, the prefix is fungible - it moves between service providers and directly supports multihoming. The biggest impact I hear from service providers is that it inverts their transit contracts - in effect, instead of the receiver's address determining its routing (it goes to his ISP, which may be very large), the sender's does (it uses *his* ISP to get to the city-or-whatever, and then hops to the receiver's ISP). Say that, and ISPs tend to get real uninterested. I'm not in favor of 10^7 routes in the backbone. I am in favor of end to end transparency at the application layer. I'm in favor of any solution that minimizes capital and operational complexity and expense. No solution on the table is pain-free; to my mind, prefix translation is the least pain, cost, and complexity among the available options. If you have another option, I'm listening. _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
