Hi Fred, Thank you very much for you kind clarification.
Sorry I haven't read through the materials you provided, I think I have understand your use case and I do have some ideas in my head, hope to hear your comments. Your scenario seems you have your own private prefix (or the prefix assigned by service provider A), and want to utilize this prefix to go through another network (e.g., service provider B). The first option in my head is tunnel. I think we can get some experience for IPv6 transition. The IETF recommend is, when the communicating nodes are in same address space (e.g., both in IPv4) and communication goes through another address space (e.g., IPv6), please go to tunnel; if the communicating nodes are in different address space (e.g., one is IPv4 and the other is IPv6), please go to translation. Is this right? Well let's go BACK to your case, you are do communicating using your private network prefix (I would like to take it as a manner of address space) and the communicating traffic goes through the network with another network prefix (i.e., the network with another address space), why not try tunnel? The tunnel endpoints may lie on your CE routers. I assume you do have your own CE routers, because you are doing "internal ISP". Another reason I prefer tunnel is security, I guess your IT department also has this requirement, and tunnel can protect your traffic well. My second option is mobility-like solution. I would like to re-mention section 4.3.4 of RFC3002. It says: "The feeling was that NAT should be easily eliminated provided efficient strategies are defined to address renumbering [17,62] and mobility [37] issues." I think mobility-like solution is worth a try. You may need deploy some special CE routers (I also take NAT66 routers as special router). The special router can do some mobility management function. Mobile IP specification [RFC3775] has already provided similar mechanism. In this approach, the address with your private prefix may be taken as home address and your CE router convert it to the address with prefix of ISP (the cloud network you are going through). Your transmitting CE router includes the home address (with your own network prefix) in the packets as Home Address Option, and your receiving CE router can get back the original address from the Home Address Option and forwards the packets to the destination host as their original bits. There are also some trouble in this approach, for example, on the destination side, the routing address (i.e., the destination address) issues. This approach can only address the difference prefix of sender side, but not the receiver side. But, we can use route optimization (there are many extensions in MEXT and NETEXT) between CE routers. I admit this is perhaps not a very good solution, but I think we can find solution to address the troubles. What do you think about these ideas? Best regards, Xiangsong > -----Original Message----- > From: Fred Baker [mailto:[email protected]] > Sent: Saturday, March 05, 2011 1:14 AM > To: Xiangsong Cui > Cc: 'NAT66 HappyFunBall' > Subject: Re: [nat66] Fwd: New Version Notification - draft-mrw-nat66-08.txt > > > 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 translates 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
