Is your intent here the same as what is built by firewalls? If so, NAT is a solution, but it is not required to achieve the goal. I suspect that what you're looking for is a firewall, not a NAT.
You might read http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security "Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service", James Woodyatt, 24-Apr-10, <draft-ietf-v6ops-cpe-simple-security-11.txt> which is a set of requirements we are developing in v6ops for stateful firewalls for IPv6 networks, which one would most likely implement in a CPE. On Apr 30, 2010, at 4:12 PM, Chris Engel wrote: > You WILL have Realms (I believe even very similar to those described in RFC > 2663) in IPv6. > > > 1) I am convinced that there WILL be NAT in IPv6....very similar to the > flavors available in IPv4. It's an open question whether it will be defined > in an RFC but it will exist. Why? Because too many people like myself will > demand it of our vendors. With that kind of economic pressure, some vendor > somewhere will bite and you'll have NAT whether you like it or not. I just > got done telling our hosting company (which we spend several hundred grand on > annually) that we will require a NAT-like solution for IPv6 and if they don't > provide one and another hosting service does we will be looking to switch > vendors. How many customers like that do you think it will take before it > becomes worthwhile for some-one to invest in building NAT66 devices? The only > thing not having any RFC's for them will do is make it likely that there are > no standards, just a hodge-podge of vendor specific solutions. > > > 2) Even without NAT, you will STILL have the concept of realms. There are > networks, that by design, have very limited or NO reachability to the general > internet. That's why ULA-R exists. > In the absence of NAT, I'm sure a very common deployment scenario for > Enterprises will be to have 2 Network address architectures. Every device on > the private network will have a ULA address and then the devices which are > intended to have some external connectivity will also be assigned a PA > address. The routers/firewalls on the network boundary will be designed NOT > to route ULA traffic...either outgoing or incoming. That would be my > deployment scheme if I had to do IPv6 without NAT. Though frankly, the plans > right now are to avoid IPv6 entirely until there is some NAT solution. > Possibly looking at doing some sort of NAT46 gateway solution if necessary > and staying on IPv4 local. > > > > I'm far from the only Network Manager that feels this way. I make purchasing > decisions for my enterprise and I've talked to guys in similar positions at > other enterprises that feel the same way about NAT that we do. The only > reason you aren't seeing vendors biting on this already is that IPv6 isn't > really on most enterprises radar screens yet. In essence there is no real > need or demand for IPv6 itself yet. > > Right now IPv6 (for Enterprises at least) is just a huge unjustified cost > center...that people who are being pro-active may dabble a little bit with to > build up some experience for the time when their may be a real need to > support it. > > > > > > > Christopher Engel > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> On Behalf Of Fred Baker >> Sent: Friday, April 30, 2010 1:39 AM >> To: Keith Moore >> Cc: [email protected] >> Subject: [SPAM] - Re: [nat66] Terminology: Definition for >> "IPv6 Realm"? - Email has different SMTP TO: and MIME TO: >> fields in the email addresses >> >> >> I would (did) argue that the issue isn't reachability... >> >> On Apr 30, 2010, at 6:30 AM, Keith Moore wrote: >> >> >> I agree that the concept of ??? (reachability >> boundaries?) needs a name. >> >> Keith >> >> >> Fine. The concept I described is relevant, even >> if (as both Brian and I point out) it is not the same as the >> one RFC 2663/3103 talk about. We'll use a different word so >> you don't have to worry about it. >> >> >> On Apr 30, 2010, at 6:14 AM, Keith Moore wrote: >> >> >> >> Even if one accepts the need for v6-v6 >> NAT (I do not) that's still not a justification for IPv6 >> addressing realms. >> >> >> Look at the "cc" line of this email. >> >> On Apr 30, 2010, at 3:11 AM, >> Keith Moore wrote: >> >> >> >> Why is there a need for >> such a concept as "IPv6 realm"? >> >> It seems to me that if >> we ever create IPv6 realms in the sense that realms exist in >> IPv4 (i.e. if we make IPv6 addresses ambiguous), we've >> irrevocably broken IPv6. >> >> And if we end up >> creating a subtly different concept in IPv6 - something like >> realms without the potential for address assignment conflicts >> - it will be confusing to call such things realms. >> >> But I really think the >> right thing to do is to make explicit that there is only one >> "realm" for the entire IPv6 address space. >> >> Keith >> >> >> We got a definition for >> "IPv4 realm", based on RFC 2663 (but also RFC 3103). >> Both RFC's are IPv4 >> oriented, not providing an explicit definition for an "IPv6 realm". >> >> This question might be >> related to NAT66, because the IPv4 realm concept is >> originating from NAT44. >> >> Does anyone know a >> correspondent definition/reference for IPv6 realm? >> >> If not, I'd like to >> offer an initial proposal for discussion, - a common realm >> term for IPv4 and IPv6: >> >> (IPv4 or IPv6 address) >> realm: is defined as a set of addresses, which share all a >> common prefix, that are mutually reachable (thus, within a >> single IP routing domain). >> >> Note: "IPv6 realm" >> definition based on the GLOBAL UNICAST ADDRESS format (ยง >> 2.5.4/RFC 4291) because this is a hierarchical format using a >> "global routing prefix", which is assigned to a "site" (i.e. >> sth like a REALM). >> Comments would be appreciated, >> Albrecht >> _____ >> RFC 2663 IP Network >> Address Translator (NAT) Terminology and Considerations >> 2.1. Address realm or realm >> >> >> >> >> An address realm is >> a network domain in which the network addresses >> are uniquely >> assigned to entities such that datagrams can be routed >> to them. Routing >> protocols used within the network domain are >> responsible for >> finding routes to entities given their network >> addresses. Note that >> this document is limited to describing NAT in >> IPv4 environment and >> does not address the use of NAT in other types >> of environment. >> (e.g. IPv6 environments) >> >> >> RFC 3103 Realm Specific >> IP: Protocol Specification >> 3. Terminology >> Private Realm >> >> A routing realm >> that uses private IP addresses from the ranges >> (10.0.0.0/8, >> 172.16.0.0/12, 192.168.0.0/16) specified in >> [ >> RFC1918 >> ], or addresses that >> are non-routable from the Internet. >> >> Public Realm >> >> A routing realm >> with unique network addresses assigned by the >> Internet Assigned >> Number Authority (IANA) or an equivalent address >> registry. >> >> >> >> >> _______________________________________________ >> nat66 mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/nat66 >> >> >> >> _______________________________________________ >> 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 >> >> >> >> >> >> http://www.ipinc.net/IPv4.GIF >> >> >> >> >> http://www.ipinc.net/IPv4.GIF >> >> http://www.ipinc.net/IPv4.GIF _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
