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 > > _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
