> -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Chris Engel > Sent: Friday, April 30, 2010 10:37 AM > To: 'Fred Baker' > Cc: Keith Moore; [email protected] > Subject: Re: [nat66] Terminology: Definition for "IPv6 Realm"? > > > A statefull firewalls is NOT an appropriate substitute for > NAT, nor is NAT an appropriate substitute for a statefull > firewall. They compliment each other and overlap in certain > areas but they don't fulfill one another's roles. > > The object, the entire goal, of NAT is to abstract the > organizations internal infrastructure from it's external > presence. That has functionality in terms of security > certainly but it also has functionality operationally. > > I'll try to be brief as this could get quite long... > > In terms of security, NAT... > > - Acts as a compensating control to help mitigate the impact > of firewall misconfigurations. The firewall itself, by > definition, cannot substitute for NAT in this arena. It is > presumed in this scenario that the firewall (filters) is the > point of failure itself. Relying on that layer/mechanism > alone means you have a single point of failure. NAT adds an > additional layer or (partial) protection. > > - NAT helps to obscure the internal network architecture. > This makes it more difficult to profile that network for > attack. Although, as been pointed out elsewhere, it is not > impossible for an attacker to conduct some profiling even in > the presence of NAT. It does require considerably more effort > and sophistication to do so with NAT in place. The analogy > being that while wall safes can be defeated, they still > provide a significant measure of protection over leaving your > valuables laying out in the open. > > - NAT aids in privacy as it helps retard the ability of > tracking an individual devices activity by IP address from > external sources.
Just for the record, that requires stateful translation in the NAT and is usually achieved via port translation (NAPT). draft-mrw-behave-nat66 does not do port translation. -d > > In terms of operability, NAT... > > - NAT reduces the impact of switching vendors by reducing the > degree to which an organization must renumber. The private > address scheme on an internal network can rename the same and > only the external address scheme needs be changed. This has > been thoroughly discussed elsewhere. > > - NAT is very useful for the reverse function as well. It > allows a network to be flexible in it's distribution and > redistribution of internal infrastructure without the need > for any changes to the external advertisement of services. > Services can be moved between devices, internal networks, > moved from a single device to a load balancer....with PAT > even split from one device (say providing SMTP & HTTP) > without any change in the external advertisement of such > services at the network level. This is incredibly useful, it > can be accomplished simply on a single interface and, is > protocol/application independent and avoids many of the > propagation/caching/timing issues caused by other methods of > service advertising such as DNS. > > - NAT allows for simplification of address management. > Typically the number of devices that need an external > advertisement of services (i.e. expect INBOUND traffic) is > only a small fraction of the totality of internal devices. > NAT allows you to manage that small pool of external > addresses on a single device/interface without any need to > impact internal address assignments. > > > > These are just a few of the more obvious areas where NAT > provides useful functionality. Note, that I certainly don't > mean to imply that NAT does not cause it's share of problems > and complications as well. However, every organizations usage > case will be different. As with every technology each > organization will need to assess the costs and benefits of it > in regards it's own unique situation and arrive at the > conclusion that makes the most sense for it's own usage. > Different organizations WILL reach different conclusions. The > concept that a significant number of organizations won't find > the benefits of NAT far outweigh the costs is (IMO) willful blindness. > > The internet needs to support a wide diversity of users with > a wide diversity of interests. I believe that such > flexibility, far more then the concept of end-to-end > transparency or end-to-end reachability is what lead to the > true success of the internet....the freedom for each > organization to utilize it in the manner that best fits that > individual organizations needs. > It is admirable to support efforts that NAT NEED not be > deployed for those organizations who deem it problematic.... > it is wrong-headed to attempt to PREVENT organizations who > find NAT useful from deploying it on their OWN network > boundaries in an IPv6 world. > > > > > Christopher Engel > > > -----Original Message----- > > From: Fred Baker [mailto:[email protected]] > > Sent: Friday, April 30, 2010 11:28 AM > > To: Chris Engel > > Cc: Keith Moore; [email protected] > > Subject: Re: [SPAM] - Re: [nat66] Terminology: Definition for > > "IPv6 Realm"? - Email has different SMTP TO: and MIME TO: > > fields in the email addresses > > > > > > 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 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
