Subject: [nat66] Terminology: Definition for "IPv6 Realm"?

From: "Schwarz Albrecht" <[email-masked]>
Date: Thu, 29 Apr 2010 00:15:24 +0200

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 <http://tools.ietf.org/html/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.

---

From: Fred Baker <[email-masked]>
Date: Thu, 29 Apr 2010 08:01:56 +0200

First let me verify assumptions on naming. When I talk about nat66, I am talking about the proposal in http://tools.ietf.org/html/draft-mrw-behave-nat66. If you're not, please proceed carefully. If you are proposing to replicate IPv4/IPv4 NAT in IPv6/IPv6 NAT without thought or change, you are probably correct. That's not the topic of this list, though.

If you are talking about network prefix translation, as proposed, reachability is not in question. The question is mutual use of prefixes. In a NAT66 world, an address as seen here as one prefix is reachable there as another prefix. Your definition depends on the IPv4/IPv4 concept that a NAT divides worlds into mutually unreachable domains. In NAT66 as defined in the nat66 spec, we have not made the world mutually unreachable. We have simply changed the prefix to make routing more scalable while we connect them.

Conceptual example.

In your domain, you are using, let's say, a ULA, and that is the only prefix by which you are known. I would want to call this your "realm". From your ISP, you are also provided with a prefix, and when the datagram from your computer crosses that domain boundary, the DMZ replaces the prefix and does whatever it is going to do about TCP/UDP checksums. In your domain, you are effectively provider-independent, able to work with multiple ISPs without renumbering equipment, and equally reachable through all of them. In ISP2's domain, you are in effect using a provider-allocated address, and routing scales as it does with any provider-allocated address.

Ditto with me, my domain, and my relationship with me set of ISPs including ISP1.

        ------         ------         ------         ------
      // My   \\     //      \\     //      \\     // Your \\
     /ULA Realm \   /    ISP1  \   /   ISP2   \   /ULA Realm \
    ||          || ||          || ||          || ||          ||
    | +---+     +---+           | |           +---+      +---+|
    | |Me |     |DMZ|         -------         |DMZ|      |You||
    | +---+     +---+           | |           +---+      +---+|
    ||          || ||          || ||          || ||          ||
     \          /   \          /   \          /   \          /
      \\      //     \\      //     \\      //     \\      //
        ------         ------         ------         ------

    |<- my realm ->|<--------  Core Realm ----->|<-your realm->|

If "you" decide to send a datagram to "Me", you ask DNS to translate my name to my address, and among others you get my address as seen by ISP1. You send it from your realm's addressing: your source address is in a ULA. It crosses the DMZ to ISP2, changing to ISP2's prefix; we now have a datagram from somewhere in ISP2 to ISP1. For ISP2, it is simply "somewhere in ISP1"; in ISP1 it is specifically somewhere at my domain. It crosses my DMZ, and now it is from your PA address to my ULA address.

If we're going to use the world "realm", I think the area the realms cover is the same as you describe, and which I show above. However, "Me" is reachable by "You" at my PA address. There is no question of non-reachability, and no question of dynamic session state in the translation.

I think in a NAT66 world, you would have to extend the definition to say that an IPv4 prefix realm is about reachability as you say; an IPv6 realm is one in which the same prefix pair is used in both the source and destination address in an IPv6 datagram.

On Apr 29, 2010, at 12:15 AM, Schwarz Albrecht wrote:

>       [
> RFC1918
> ], or addresses that are non-routable from the Internet.
> 
>    Public Realm
> 
> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66

http://www.ipinc.net/IPv4.GIF

---

From: Fred Baker <[email-masked]>
Date: Thu, 29 Apr 2010 10:43:56 +0200

> I think in a NAT66 world, you would have to extend the definition to say that an IPv4 prefix realm is about reachability as you say; an IPv6 realm is one in which the same prefix pair is used in bo…

I re-read this, and confused myself; hence, I probably confused someone else. Let me try again.

Within an addressing realm as considered in a GSE architecture, an ILNP architecture, or a NAT66 architecture, every observer of an address uses the same prefix for that address. When you cross a DMZ, which changes the prefix of either the source or the destination address, you have changed realms.

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Apr 2010 22:11:21 -0400

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
> *(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).
> *RFC 2663* IP Network Address Translator (NAT) Terminology and Considerations
>
>
> *RFC 3103* Realm Specific IP: Protocol Specification
> 3.  Terminology
>    Private Realm
>
>       [RFC1918 <http://tools.ietf.org/html/rfc1918>], or addresses that are non-routable from the Internet.
>
>    Public Realm
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Apr 2010 14:26:46 +1200

> realms exist in IPv4 (i.e. if we make IPv6 addresses ambiguous), we've

I agree. To be clear, the NAT66 draft does *not* do this.

There is of course a very real possibility of regions of IPv6
address space which are not mutually reachable, due to firewalls
or even more aggressive forms of walled garden. But that doesn't
make them realms in the RSIP sense (if you don't know about
RSIP, see RFC 3102...3105).

   Brian

---

From: Fred Baker <[email-masked]>
Date: Fri, 30 Apr 2010 06:03:44 +0100

Look at the "cc" line of this email.

On Apr 30, 2010, at 3:11 AM, Keith Moore wrote:

> 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

---

From: Keith Moore <[email-masked]>
Date: Fri, 30 Apr 2010 01:14:24 -0400

Even if one accepts the need for v6-v6 NAT (I do not) that's still not a
justification for IPv6 addressing realms.

---

From: Fred Baker <[email-masked]>
Date: Fri, 30 Apr 2010 06:26:08 +0100

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.

---

From: Keith Moore <[email-masked]>
Date: Fri, 30 Apr 2010 01:30:28 -0400

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.
>
>> Even if one accepts the need for v6-v6 NAT (I do not) that's still
>> not a justification for IPv6 addressing realms.

---

From: Fred Baker <[email-masked]>
Date: Fri, 30 Apr 2010 06:38:56 +0100

I would (did) argue that the issue isn't reachability...

---

From: Chris Engel <[email-masked]>
Date: Fri, 30 Apr 2010 11:12:30 -0400

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-masked] [mailto:[email-masked]]
> On Behalf Of Fred Baker
> Sent: Friday, April 30, 2010 1:39 AM
> To: Keith Moore
> Cc: [email-masked]
> Subject: [SPAM] - Re: [nat66] Terminology: Definition for
> "IPv6 Realm"? - Email has different SMTP TO: and MIME TO:
> fields in the email addresses
>
>
>               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.
>
>
>                       Even if one accepts the need for v6-v6
> NAT (I do not) that's still not a justification for IPv6
> addressing realms.
>
>
>                                       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).
>                                       RFC 2663 IP Network
> Address Translator (NAT) Terminology and Considerations
>                                          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
>                                             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
>                                             A routing realm
> with unique network addresses assigned by the
>                                             Internet Assigned
> Number Authority (IANA) or an equivalent address
>                                             registry.
>
>
>
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 30 Apr 2010 16:27:43 +0100

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.

---

From: james woodyatt <[email-masked]>
Date: Fri, 30 Apr 2010 10:08:59 -0600

On Apr 30, 2010, at 09:12, Chris Engel wrote:
> 
> [...]
> 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.
> [...]

Sounds like you have no clear use for NAT66, and you can live indefinitely on IPv4-only.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Keith Moore <[email-masked]>
Date: Fri, 30 Apr 2010 12:21:41 -0400

> You WILL have Realms (I believe even very similar to those described in RFC 2663) in IPv6.
Perhaps, but it's irresponsible for IETF to encourage them.  And there
is such a thing as a self-fulfilling prophecy.  By planning for realms
in IPv6 we would be helping to bring them about. 

People are going to make poor choices here and there, and sometimes
widely.   IETF's job is to specify what will work well, not to specify
how to do things that can't be made to work well.

Keith

---

From: Chris Engel <[email-masked]>
Date: Fri, 30 Apr 2010 13:37:22 -0400

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.

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

> From: Fred Baker [mailto:[email-masked]]
> Sent: Friday, April 30, 2010 11:28 AM
> To: Chris Engel
> Cc: Keith Moore; [email-masked]
> Subject: Re: [SPAM] - Re: [nat66] Terminology: Definition for
> 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
> 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.
>
>
> > 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
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Fred Baker
> >> Subject: [SPAM] - Re: [nat66] Terminology: Definition for "IPv6
> >> Realm"? - Email has different SMTP TO: and MIME TO: fields in the
> >> email addresses
> >>
> >>
> >>              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.
> >>
> >>
> >>                      Even if one accepts the need for
> v6-v6 NAT (I do
> >> not) that's still not a justification for IPv6 addressing realms.
> >>
> >>
> >>                              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
> >>                                      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
> >>                                      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).
> >>                                         An address realm
> is a network
> >> domain in which the network addresses
> >>                                         are uniquely assigned to
> >> entities such that datagrams can be routed
> >>                                         IPv4 environment
> and does not
> >> address the use of NAT in other types
> >>                                            Internet
> Assigned Number
> >> Authority (IANA) or an equivalent address
> >>                                            registry.
> >>
> >>
> >>
> >>

---

From: Keith Moore <[email-masked]>
Date: Fri, 30 Apr 2010 13:52:34 -0400

> 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…
IETF cannot prevent people from doing things that do harm to themselves
or to the network.  But IETF's job is to recommend what will work well
for the Internet as a whole, not to optimize for corner cases at the
expense of the whole.  

Given two different architectures, one without NATs and one with NATs,
you solve certain problems (like hiding internal network architecture)
in different ways.  But the solution without NATs is less complex, more
reliable, flexible, cheaper, and more adaptable to a wide variety of
applications.  The choice is clear.

---

From: Chris Engel <[email-masked]>
Date: Fri, 30 Apr 2010 14:07:00 -0400

Keith,

If there is a real desire to do something, people will do it regardless of what IETF wishes or pronounces. Did NAT in IPv4 require an RFC before there were adoptions of it?

I would think the wiser course for IETF, rather then to attempt to control peoples behavior...something which it cannot do in practicality.... would be to recognize when there is a legitimate demand for some function/technology....and provide some guidance/standards about how that functionality can be implemented...so that there is a higher level of predictability about how individual implementations of such functionality would work.

I a remain entirely unconvinced that NAT cannot "work well". It is quite widely deployed currently on the IPv4 net....and the internet has not ground to a halt because of it. Nothing about the basic purpose and usage of the internet changes just because we switch to IPv6 (if it does then the protocol is poorly conceived and designed), merely some of the details of the method used to achieve those ends.

"Abstraction" and limits to reachability are important end goals for many organizations today, they will continue to be so tomorrow. IETF can either accept that or stick it's head in the sand and whistle while the rest of the world goes on doing what it wants to anyway.

Personally, I'd rather have standards...so when all those implementations of NAT DO break some designers shiny new protocol...he can at least have some level of predictability about HOW they are doing so.

Christopher Engel

> From: Keith Moore [mailto:[email-masked]]
> Sent: Friday, April 30, 2010 12:22 PM
> To: Chris Engel
> Cc: 'Fred Baker'; [email-masked]
> Perhaps, but it's irresponsible for IETF to encourage them.
> And there is such a thing as a self-fulfilling prophecy.  By
> planning for realms in IPv6 we would be helping to bring them about.
>
> People are going to make poor choices here and there, and
> sometimes widely.   IETF's job is to specify what will work
> well, not to specify how to do things that can't be made to
> work well.
>
> Keith
>
>
>

---

From: Keith Moore <[email-masked]>
Date: Fri, 30 Apr 2010 14:08:49 -0400

>
> Keith,
>
> If there is a real desire to do something, people will do it regardless of what IETF wishes or pronounces. 
>
> [...]
That's a bit like saying that some people will go to Hell no matter
what, so religions should encourage everyone to do as much harm as
possible while they're alive.

Keith

---

From: Chris Engel <[email-masked]>
Date: Fri, 30 Apr 2010 15:26:08 -0400

Well, perhaps if you view the IETF as a "religion" and NAT as something which violates it's dogma that analogy makes sense.

Here is the thing, not everyone agree's on a common defintion of "harm". Is sex out of wedlock "harm"? How bout eating pork? Drinking wine? It all depends upon the "religion" of the person you ask.

Regardless of that, the scientificaly responsible thing for organizations that are concerned with public health issues to do is talk about condom use (including the fact that they are not foolproof). It isn't going to cause people who regard sex out of wedlock as "sinful" from going wild... and isn't going to stop people who don't from engaging in that activity. It's just going to mitigate some of the more negative side effects that behavior might cause.

The factual thing that can be said about NAT is that it obscures the literal IP address assigned to an end device from a source on the other side of the NAT boundary. For some that is a desired effect for others it's an undesirable problem. Where you fall on that spectrum is more akin to religion. IETF is never going to get people to reconcile thier conflicting interests there. What it can do is describe the effects that obscurity causes...it can also describe the method by which that obscurity can be performed....so at least everyone can understand and predict how it works...making it easier to account for it when it happens.

You are not going to achieve that level of "obscurity" without some form of address translation....and any solution that you do provide to achieve that obscurity will have much of the same side effects that todays NAT does.

Christopher Engel

> Sent: Friday, April 30, 2010 2:09 PM
> To: Chris Engel
> Subject: Re: [nat66] Terminology: Definition for "IPv6 Realm"?
>
>
>       Keith,
>
>       If there is a real desire to do something, people will
> do it regardless of what IETF wishes or pronounces.
>
>
>       [...]
>       I would think the wiser course for IETF, rather then to
> attempt to control peoples behavior...something which it
> cannot do in practicality.... would be to recognize when
> there is a legitimate demand for some
> function/technology....and provide some guidance/standards
> about how that functionality can be implemented...so that
> there is a higher level of predictability about how
> individual implementations of such functionality would work.
>
>
> That's a bit like saying that some people will go to Hell no
> matter what, so religions should encourage everyone to do as
> much harm as possible while they're alive.
>
> Keith
>
>

---

From: Keith Moore <[email-masked]>
Date: Fri, 30 Apr 2010 15:44:36 -0400

> Well, perhaps if you view the IETF as a "religion" and NAT as something which violates it's dogma that analogy makes sense.
Religions are at their best when they give people practical, achievable
ways to live their lives well, and in such a way as to benefit not only
themselves, but also others.  

Similarly, IETF is at its best when it tells people practical,
achievable ways to build and run networks in such a way that not only
the enterprise network works well, but the whole Internet supports a
wide diversity of applications for everyone's benefit.
> Regardless of that, the scientificaly responsible thing for organizations that are concerned with public health issues to do is talk about condom use (including the fact that they are not foolproof…
So fine.   If you can figure out how to tell people to have NATs in
their networks without their doing signfiicant harm, by all means do so.
 But nobody has figured this out yet, and NATs have been around for 15+
years by now.  

I've tried to do that myself with NAT-XC, and while I think that NATs
that are explicitly controlled by their endpoints are a lot better than
those that try to outsmart their endpoints, I certainly wouldn't say
that they don't still do harm.  I can only justify them as a transition
mechanism to get to pure IPv6, and as a band-aid to allow the occasional
legacy IPv4 only host or app to work for a bit longer.

The people who still claim that NATs do little harm are either in
denial, malicious, or both.

>
>
> The factual thing that can be said about NAT is that it obscures the literal IP address assigned to an end device from a source on the other side of the NAT boundary. For some that is a desired effect for others it's an undesirable problem. 
You're grossly understating the harm caused by NATs, and you know it.  
> Where you fall on that spectrum is more akin to religion. 
Where I fall on the spectrum is practicality.  I've done the analysis
for large numbers of use cases and I know which way works better
overall.  There's really no comparison.

Of course religion has a dark side too.  The worst aspect of religion is
when it reinforces prejudices that do harm.    Which is a very good
description of what promoting NATs does.
> IETF is never going to get people to reconcile thier conflicting interests there. 
>   
Perhaps not, but that's not an excuse for IETF to be deliberately
dishonest or to promote harmful practices.
>
> You are not going to achieve that level of "obscurity" without some form of address translation...
Incorrect.  There are lots of ways to route traffic within an enterprise
without exposing the internal network hierarchy in the address.

Keith

---

From: james woodyatt <[email-masked]>
Date: Fri, 30 Apr 2010 14:16:22 -0600

On Apr 30, 2010, at 13:26, Chris Engel wrote:
> 
> You are not going to achieve that level of "obscurity" without some form of address translation....

That's not true.  It can also be done with encapsulation.  RFC 3103 is an existence proof.

> and any solution that you do provide to achieve that obscurity will have much of the same side effects that todays NAT does.

Also not true.  As RFC 3103 shows.

---

From: Chris Engel <[email-masked]>
Date: Fri, 30 Apr 2010 16:40:21 -0400

Ok, Keith I'll bite how do we route traffic from my machine to your machine while not informing you of the actual IP address assigned to my machine, without using some iteration of Address Translation and without causing the exact same sort of side effects that NAT currently causes?

I can assure you that my deploying NAT on my own network boundary does you no more harm then my eating pork or having sex out of wedlock would. There may be some negative side effects for me, but that's my bagage to deal with. There may even be some negative side effects for those who choose to interact with me...but that choice of interaction is entirely voluntary. Furthermore I accept the fact that if I really want to interact with those idividuals the onus is on me to put together an acceptable work around.

So what "harm" is my deployment of NAT causing you?

- You can't initiate access to any devices on my network unless I explicity advertise them as an external service. Guess what, I don't want you to...and you don't have a right to....even without NAT, that would be prevented by my firewall filter rules.

- Certain communication protocols/applications won't work between us unless I've made specific provisions for those protocols/applications to function across my NAT boundary (ALG's).... guess what, I don't want them to....and you don't have a right to expect them to do so. In the absense of NAT I would still make my best effort to prevent arbitrary applications/protocols from functioning across my network boundary without some sort of specific provision to enable them.

- You aren't able to easly profile my internal network. Again, I don't want you to...nor do you have a right to. You have no more right to know the IP address of any particular device on my network then you do to know who I bought it from or how much I paid for it.

- You DO have a right to know that packets coming in to your network are coming from my network. My use of NAT in no way prevents that from occuring. You do have a right not to recieve packets from my network if you request me not to send them. My use of NAT in no way prevents that either.

So I'm still waiting to hear the ACTUAL "harm" my deployment of NAT is causing you?

Christopher Engel

> Sent: Friday, April 30, 2010 3:45 PM
> To: Chris Engel
>       Well, perhaps if you view the IETF as a "religion" and
> NAT as something which violates it's dogma that analogy makes sense.
>
>
> Religions are at their best when they give people practical,
> achievable ways to live their lives well, and in such a way
> as to benefit not only themselves, but also others.
>
> Similarly, IETF is at its best when it tells people
> practical, achievable ways to build and run networks in such
> a way that not only the enterprise network works well, but
> the whole Internet supports a wide diversity of applications
> for everyone's benefit.
>
>
>
>       Here is the thing, not everyone agree's on a common
> defintion of "harm". Is sex out of wedlock "harm"? How bout
> eating pork? Drinking wine? It all depends upon the
> "religion" of the person you ask.
>
>       Regardless of that, the scientificaly responsible thing
> for organizations that are concerned with public health
> issues to do is talk about condom use (including the fact
> that they are not foolproof). It isn't going to cause people
> who regard sex out of wedlock as "sinful" from going wild...
> and isn't going to stop people who don't from engaging in
> that activity. It's just going to mitigate some of the more
> negative side effects that behavior might cause.
>
>
> So fine.   If you can figure out how to tell people to have
> NATs in their networks without their doing signfiicant harm,
> by all means do so.  But nobody has figured this out yet, and
> NATs have been around for 15+ years by now.
>
> I've tried to do that myself with NAT-XC, and while I think
> that NATs that are explicitly controlled by their endpoints
> are a lot better than those that try to outsmart their
> endpoints, I certainly wouldn't say that they don't still do
> harm.  I can only justify them as a transition mechanism to
> get to pure IPv6, and as a band-aid to allow the occasional
> The people who still claim that NATs do little harm are
> either in denial, malicious, or both.
>
>
>
>
>
>       The factual thing that can be said about NAT is that it
> obscures the literal IP address assigned to an end device
> from a source on the other side of the NAT boundary. For some
> that is a desired effect for others it's an undesirable problem.
>
> Where I fall on the spectrum is practicality.  I've done the
> analysis for large numbers of use cases and I know which way
> works better overall.  There's really no comparison.
>
> Of course religion has a dark side too.  The worst aspect of
> religion is when it reinforces prejudices that do harm.
> Which is a very good description of what promoting NATs does.
>
>
> Perhaps not, but that's not an excuse for IETF to be
> deliberately dishonest or to promote harmful practices.
>
>
>
>       You are not going to achieve that level of "obscurity"
> without some form of address translation...
>
> Incorrect.  There are lots of ways to route traffic within an
> enterprise without exposing the internal network hierarchy in
> the address.
>
>
> Keith
>
>
>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 30 Apr 2010 13:55:10 -0700

> Ok, Keith I'll bite how do we route traffic from my machine to your machine while not informing you of the actual IP address assigned to my machine, without using some iteration of Address Translat…

One way is using an encapsulation mechanism such that the endhost
knows the IP address that
will be exposed.   Imagine putting Mobile-IP style home agents at your
network border:
a host maintains (or creates as needed) a tunnel to that border host
when it needs to reach
an endpoint outside the local galumbit; the home agent would also
presumably be permitted
to reach hosts inside the galumbit when administrative rules for that
have been satisfied.

There are other trade-offs, of course, but it looks to me that
existing technology
enable you to design a network border with the security properties you
desire without NAT.
You get a very short-legged triangle route (similar to mobile IP's
triangle, but with much less
practical effect), but this has a pretty different impact from NAT.

[I'm using the term "galumbit" above because realm, zone, and domain
are off-limits and Fred
doesn't want to talk about reachability.  I hope you know the galumbit
when you see it, as
the thing inside those borders]

Just my opinion, of course,

regards,

Ted

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 01 May 2010 09:46:21 +1200

On 2010-05-01 06:07, Chris Engel wrote:
...
> If there is a real desire to do something, people will do it
> regardless of what IETF wishes or pronounces. Did NAT in IPv4
> require an RFC before there were adoptions of it?

Yes. Two, actually.

RFC 1597 Address Allocation for Private Internets. March 1994.
(Status: INFORMATIONAL)
RFC 1631 The IP Network Address Translator (NAT). May 1994.
(Status: INFORMATIONAL)

That's exactly why we published something different for IPv6:

RFC 4864 Local Network Protection for IPv6. May 2007.
(Status: INFORMATIONAL)

and why, as has been mentioned, we are publishing
draft-ietf-v6ops-cpe-simple-security.

I think there's a good chance that there will be NAT66 in
the market, but to minimise the damage, it needs to be
like draft-mrw-behave-nat66.

    Brian

---

From: Chris Engel <[email-masked]>
Date: Fri, 30 Apr 2010 18:20:22 -0400

James,

Let me see if I have the functional nature of RISP correct (haven't worked with it before):

1) The devices that RISP hosts have permanent non-routable IP address space. RFC 3103 says RFC 1918 space....I'm assuming this would by ULA space in IPv6.

2) The RISP Gateway has a pool of availble PA addresses that it can assign.

3) The RISP host negotiates a short lease (4 or 5 seconds) for one of these PA addresses from it's RISP gateway and binds it.

4) The RISP host then uses that PA address to communicate directly for the duration of the (4 or 5 second) lease.

Is that essentialy correct?

If it is, this leads me to a few questions...

 - Either the the RISP host must communicate with a communication partner that has a staticaly assigned IP to initiate a communication session or the RISP hosts must have some out-of-band method to exchanging thier leased IP info.... else how would one RISP host ever initiate a communication session with another? Furthermore, how would the recieving RISP host know to obtain a PA lease without some out of band method for communicating that it was about to recieve an incoming communication?

 - If there is some out-of-band regsitration of RISP hosts then that effectively defeats the purposes of "obscuring" the devices IP address since another RISP host can query the out-of-band service to obtain the IP address for each RISP host whenever it wants to do so. Although this might not be horrible depending upon the kind of security required to query the out-of-band service.

 - What happens when the RISP host recieves INBOUND communication on it's leased PA from a device which is not it's current communication partner? Under dynamic NAT this would go nowhere since there isn't an entry in the NAT flow table that corresponds to that session. Am I left with a single point of failure (my FW filter rules) for stopping these...or does the RISP gateway functionaly stop it?

 In effect, the only way I could see this practicaly working would be if the RISP effectively permanently held open a lease...and either that lease was long term....or if it did change every few seconds then there would have to be some sort of automatic registration scheme with some sort of out-of-band registry.

In either case, it wouldn't be doing what I want...since I don't want my hosts accessible/addressable unless THEY initiate communications. If my hosts are registering with some sort of out of band service then I've just introduced another method of profiling my devices...unless that service has a really air-tight method of establishing trust relationships. If the leases are effectively semi-permanent then it doesn't sound much more obscure then DHCP....and would seam to have alot of the same overhead and drawbacks.

It doesn't sound like a terrible solution...but I still don't see why I would prefer it over NAT. It sounds like it has many (though not all) of the same drawbacks as NAT, may miss some of the functionality NAT provides.... and doesn't sound like it has any less overhead or complications that implimenting ALG's in NAT.

If NAT provides me exactly the functionality I want now....doesn't break any protocols/applications I want to use. The applications/protocols it breaks I ACTUALY WANT broken.... why would I want to switch to RISP instead?

But thank you for the information on it....it was interesting regardless.

Christopher Engel

> From: james woodyatt [mailto:[email-masked]]
> Sent: Friday, April 30, 2010 4:16 PM
> To: Chris Engel
> Cc: NAT66 HappyFunBall
> > and any solution that you do provide to achieve that obscurity will
> > have much of the same side effects that todays NAT does.
>

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Sat, 1 May 2010 01:21:42 +0200

I'd like to come back to the concept of a realm and a possible
definition for "IPv6 realm".
Thanks Fred to point out on the aspect of "mutual reachability".

Question: If a realm is characterized by reachability, then I would
assume that an "IPv6 realm" would equate to an "IPv6 routing domain",
right?

A follow-up consideration:
There'll be "IPv6 islands" during the transition from V4-to-V6.
Such islands are per se single IPv6 routing domains ("and then perhaps
"IPv6 realms").

Thanks,
Albrecht

> On Behalf Of Chris Engel
> Sent: Samstag, 1. Mai 2010 00:20
> To: 'james woodyatt'
> Cc: NAT66 HappyFunBall
> 1) The devices that RISP hosts have permanent non-routable IP 
> address space. RFC 3103 says RFC 1918 space....I'm assuming 
> this would by ULA space in IPv6.
> 
> 3) The RISP host negotiates a short lease (4 or 5 seconds) 
> for one of these PA addresses from it's RISP gateway and binds it.
> 
> 4) The RISP host then uses that PA address to communicate 
> directly for the duration of the (4 or 5 second) lease.
> 
>  - Either the the RISP host must communicate with a 
> communication partner that has a staticaly assigned IP to 
> initiate a communication session or the RISP hosts must have 
> some out-of-band method to exchanging thier leased IP 
> info.... else how would one RISP host ever initiate a 
> communication session with another? Furthermore, how would 
> the recieving RISP host know to obtain a PA lease without 
> some out of band method for communicating that it was about 
> to recieve an incoming communication?
> 
>  - If there is some out-of-band regsitration of RISP hosts 
> then that effectively defeats the purposes of "obscuring" the 
> devices IP address since another RISP host can query the 
> out-of-band service to obtain the IP address for each RISP 
> host whenever it wants to do so. Although this might not be 
> horrible depending upon the kind of security required to 
> query the out-of-band service.
> 
>  - What happens when the RISP host recieves INBOUND 
> communication on it's leased PA from a device which is not 
> it's current communication partner? Under dynamic NAT this 
> would go nowhere since there isn't an entry in the NAT flow 
> table that corresponds to that session. Am I left with a 
> single point of failure (my FW filter rules) for stopping 
> these...or does the RISP gateway functionaly stop it?
> 
>  In effect, the only way I could see this practicaly working 
> would be if the RISP effectively permanently held open a 
> lease...and either that lease was long term....or if it did 
> change every few seconds then there would have to be some 
> sort of automatic registration scheme with some sort of 
> out-of-band registry.
> 
> In either case, it wouldn't be doing what I want...since I 
> don't want my hosts accessible/addressable unless THEY 
> initiate communications. If my hosts are registering with 
> some sort of out of band service then I've just introduced 
> another method of profiling my devices...unless that service 
> has a really air-tight method of establishing trust 
> relationships. If the leases are effectively semi-permanent 
> then it doesn't sound much more obscure then DHCP....and 
> would seam to have alot of the same overhead and drawbacks.
> 
> It doesn't sound like a terrible solution...but I still don't 
> see why I would prefer it over NAT. It sounds like it has 
> many (though not all) of the same drawbacks as NAT, may miss 
> some of the functionality NAT provides.... and doesn't sound 
> like it has any less overhead or complications that 
> implimenting ALG's in NAT.
> 
> If NAT provides me exactly the functionality I want 
> now....doesn't break any protocols/applications I want to 
> use. The applications/protocols it breaks I ACTUALY WANT 
> broken.... why would I want to switch to RISP instead?
> 
> without some 
> > > form of address translation....
> >

---

From: james woodyatt <[email-masked]>
Date: Fri, 30 Apr 2010 17:43:01 -0600

> If NAT provides me exactly the functionality I want now....doesn't break any protocols/applications I want to use. The applications/protocols it breaks I ACTUALY WANT broken.... why would I want to…

I don't even know why you would want IPv6.  It doesn't seem to buy you anything that you don't already have with IPv4/NAT.

I was merely countering your assertion that NAT is required to prevent unique-local routing topology from being exposed to exterior domains.  It isn't, as the example of RSIP demonstrates.  Concerns about reachability and stateful flow tracking can be handled orthogonally with things like I-D.ietf-v6ops-cpe-simple-security.

Look, I'm not trying to persuade you that you shouldn't use NAT at your borders-- indeed, as I said before, your plan to stay IPv4-only on local networks and to rely on NAT46 gateways to communicate with exterior IPv6 networks is a perfectly reasonable one.  You should go do that.  It sounds to me like the optimal solution for you.