Subject: [renum] IPv4 deployment scenarios to minimise renumbering costs

From: RJ Atkinson <[email-masked]>
Date: Fri, 3 Dec 2010 09:45:12 -0500

There is at least one IPv4 deployment scenario that
is pretty common right now in several areas of the 
world, works pretty well for enterprise users,
provides practical amounts of provider-independence,
and probably would be worth documenting.

A previous employer of mine *by choice* (specifically, 
due to internal security policy choices) decided to put 
nearly the whole organisation into private address space.
The exception was that public-facing content servers
were in global-scope address space, on a network segment
outside the "trusted zone" of the organisation.  By
policy, access initiated from outside the trusted
zone to any node inside the trusted zone was prohibited.
So it was actively undesirable to have interior nodes
with global-scope address space.  I believe these are
not unusual choices for an enterprise to make these days.

While they easily could have obtained sufficient IPv4
address space (and likely still could today) from
their upstream providers, they preferred to deploy
using private addressing with NAT-capable IPsec-capable
firewalls at the edge(s) of each site within the
organisation.

Each site within the organisation had its own upstream
connectivity -- managed/selected/paid by centralised
IT services folks.  This let the IT folks reduce cost
by selecting lower-cost providers on a site-specific
basis.

Connectivity between sites of the organisation was
enabled using IPsec encrypted tunnels between those
same edge firewall devices.

This had the effect of offering provider-independence,
because only the (1 or 2) Firewall devices at a given site 
needed to renumber their exterior network interfaces 
if that site's upstream provider set changed.  

Crucially, by using MBOX-style identity types 
(e.g. [email-masked]) in the IKE configurations, 
there was no need to reconfigure firewalls or nodes 
at other sites if a given site's upstream connectivity
changed.

For M&A, an acquired organisation's sites would be
renumbered into a suitable chunk of private address
space and migrated into the above schema.  Because
most organisations now use DHCP, the amount of 
manual configuration involved in site renumbering
was minimised and turned out to be quite tractable
to undertake manually.

This doesn't help everyone and isn't completely general, 
but it does apply to a very common type of user organisation.
It could be very helpful to document the above for the
benefit of those organisations who choose to use it.

I suspect there are other specific items that would be
useful to folks with IPv4 deployments.  So I think that
IPv4 efforts ought to remain within-scope, even if IPv6
were perceived as the "sweet spot" for improvements.

Yours,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Dec 2010 11:11:29 +1300

> not unusual choices for an enterprise to make these days.

Sad but true. I believe that draft-mrw-nat66 is aimed at
this model, and draft-troan-multihoming-without-nat66 is
aimed against it. We could consider documenting this approach,
but of course it doesn't affect the subnet-reorganization
form of renumbering (i.e. renumbering regardless of the
"address independence" property).

    Brian

> _______________________________________________
> renum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/renum
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 3 Dec 2010 16:35:05 -0600

On Dec 3, 2010, at 4:11 PM, Brian E Carpenter wrote:

>> A previous employer of mine *by choice* (specifically, due to internal security policy choices) decided to put nearly the whole organisation into private address space. The exception was that public-facing content servers were in global-scope address space, on a network segment outside the "trusted zone" of the organisation. By policy, access initiated from outside the trusted zone to any node inside the trusted zone was prohibited. So it was actively undesirable to have interior nodes with global-scope address space. I believe these are not unusual choices for an enterprise to make these days.
> 
> Sad but true. I believe that draft-mrw-nat66 is aimed at this model

Then you haven't bothered to understand the NAT66 (or the ILNP, or 8+8, or the GSE) model. This is the biggest single problem that we who are working in this model have - people who see the acronym and both stop thinking and stop reading. Pardon me for being insulting; I'm a little insulted that you of all people haven't worked this out.

Please read slide 33 of http://www.ietf.org/proceedings/73/slides/behave-14.pdf

Stateless network prefix provides absolutely no firewall-like capabilities. It provides a translation of prefixes, and therefore every address in the translated prefix, between one domain and another, enabling an edge network to act independently of its upstream networks and therefore think of itself as PI, while allowing all of its upstreams to treat it as PA and aggregate routing accordingly.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Dec 2010 13:03:23 +1300

> Then you haven't bothered to understand the NAT66 (or the ILNP, or 8+8, or the GSE) model. This is the biggest single problem that we who are working in this model have - people who see the acronym…

Oops, I wrote in too few words after too little thought and misreading
Ran's message. The NAT66 draft is all about address independence,
a property also conferred by NAT44.

Of course I agree that the 'security' arguments for NAPT44 are bogus.
Sorry about the confusion.

   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 3 Dec 2010 16:05:08 -0800

> ...and therefore think of 
> itself as PI, while allowing all of its upstreams to treat it 
> as PA and aggregate routing accordingly.

What's that? Someone said "PI", and Teco didn't even jump
in with a disparaging remark?

You all are talking about various solution ways forward
all the while telling me to pipe down. You really ought
to go have a look at IRON, RANGER, VET and SEAL.

Here is the lastest in the series, called "Provider-
Managed IRON", which I think you will see strikes a
happy balance between PI and PA:

http://www.ietf.org/id/draft-templin-iron-pm-00.txt

Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Dec 2010 13:27:36 +1300

Fred,

This isn't a WG and we don't have a formal charter. But personally
I don't see much point in rehashing the last 15 years of discussion
of PI versus PA and what might happen if we deployed a completely
new architecture.  That doesn't preclude making the observation
that certain causes of renumbering won't apply if certain types
of address independence are in place. But the operational problem
isn't there. It's in what do we do when we must renumber anyway.

Please everybody, as I said at the start, re-read RFC 5887.

If you don't accept its conclusion that renumbering is sometimes
unavoidable, I think that point should be discussed elsewhere.

IMHO it's quite legitimate in that context to observe, without
extensive analysis, that address-independence techniques reduce
the cases in which renumbering is needed. That's why I
misinterpreted Ran's message and annoyed Fred. But it ends there;
the problem on the table is what to do when renumbering *is*
necessary.

Regards
   Brian

---

From: Fred Baker <[email-masked]>
Date: Fri, 3 Dec 2010 19:50:02 -0600

On Dec 3, 2010, at 6:27 PM, Brian E Carpenter wrote:

> the problem on the table is what to do when renumbering *is* necessary.

Works for me. Have you considered the network management model I threw out?

---

From: Fred Baker <[email-masked]>
Date: Fri, 3 Dec 2010 21:24:34 -0600

On Dec 3, 2010, at 7:57 PM, Brian E Carpenter wrote:

> we probably need to hear a bit more discussion before we draw firm conclusions.

OK. Read draft-iab-ip-model-evolution...

Let's all agree that the things that are actually hard about renumbering - the places where people take shortcuts that the sysadmin doesn't know about or can't change - aren't going to be affected by anything we come up with, whether it's a protocol, a data model, or whatever. So we're solving what the sysadmin can solve, and very explicitly telling people that if they don't collaborate with their sysadmin our sympathy will be short-lived. We can therefore limit our scope to things the sysadmin will systematically know and want to keep track of. We're making his job easy, and making anything that makes it hard Someone Else's Fault that he can beat them with a stick over.

I submit that this is, in some level of specificity and some level of aggregation, nodes and subnets in his network, and the ACLs, Route Maps, and DNS entries that are important to that.

I'm starting from the assumption that this management model is designed to manage numbering and nothing else. Yes, it will expand or get folded into something else related to SLAs, counters, and heaven only knows what else; For right now, that is 100% off the table. We're dealing with the cases where IP addresses or prefixes get written into <something> and might need to later be changed.

I for one am OK with presuming a protocol like DHCP as opposed to NetConf or SNMP. One of the things I'm thinking about are very small devices like sensors, and I'm not persuaded that heavy protocols are required. That said, I do believe that NetConf or whatever are options. They're just not the only options.

But back to the management model...

So I am assuming that there is a set of subnets (which have prefixes among other attributes) and a set of nodes (which have interfaces, which are in turn connected to subnets and have addresses and roles). Architecturally, I think MIF would be incredibly simpler if they did what we did with Multilink PPP: IP has an interface which in turn has a set of interfaces it depends on, and how that is handled is a characteristic of the group of interfaces. So I'm going to suggest we model it that way: an IP interface is linked to a set of physical interfaces, and might not be the only IP interface linked to that set.

                    Service Interface
            ------++--------------++-------
                          IP
            ------++------++------++-------
       IP       +---+   +---+   +---+
    Interfaces  |   |   |   |   |   |
                +-+-+   +-+-+   +-+-+
                 / \      |       |
              +-++ ++-+ +-+-------+-+
    Physical  |  | |  | |           |
    Interfaces++-+ ++-+ +----+------+
               |    |        |
               |    |        |

The illustrated IP node might have one subnet that uses both its wired and its wireless ports, with it doing an ND proxy between them (Thing on the left), and it might have two subnets on the same Ethernet (thing on the right). I'll break down and presume that every interface on IP's bottom side has a subnet; I'll presume that the address on that subnet might be a link-local address or might be in a global scope prefix. It will make things easier to talk about. Yes, this doesn't describe IPv4 unnumbered point to point connectivity, but I'll hand-wave that for the moment. It's a subnet with a magic address.

So:
	Network:
		Optional set of networks
		Optional set of subnets

	Set of subnets:
		zero or more subnets

	subnet:
		prefix
		routing protocol
		optional route announcement policy
		optional route acceptance policy
		<TBD>

	Set of nodes:
		zero or more nodes

	attributes of a node:
		set of IP interfaces
		a default set of roles (if role is not specified on an interface, this is inherited)
		<TBD>

	attributes of an IP interface:
		a subnet
		an address in that subnet's prefix
		set of physical interfaces
		a set of roles
		a forwarding ACL
		<TBD>

	attributes of a prefix:
		a string of bits
		a length
		a set of roles

Yes, these objects have methods. We can create and destroy them all. An IP interface has a method for associating it with a subnet and for disassociating it from a subnet. If it becomes associated with a subnet, we can assume it learns a prefix from the subnet and forms (somehow) an address in it. That might be implemented by SLAAC or DHCP, I don't care. If we destroy a subnet that is currently attached to a set of interfaces on various nodes, I presume that it is detached from those interfaces in the process of being destroyed. If we destroy a node, It is presumably detached from all subnets it is attached to.

What's with a network? Well, if I have a large IS-IS network, I will model that as one network containing a bunch of networks (areas) which in turn contain subnets which in turn connect hosts. Note, however, that my definition is recursive. I don't know what multiple levels of recursion necessarily means right now, but I'd rather leave the flexibility (NIMROD) than make it go away right now. I'm imagining outfits like Boeing, that might have large BPG networks connecting OSPF/IS-IS networks that in turn have areas...

There's an interaction with DNS here somewhere. We have domains full of names, those names have sets of addresses associated with them, and hosts (interfaces?) have sets of names associated with them. When we add a subnet to an IP interface that we have created on a node, we may want to add that IP address to some or all of the names of that device; we will need to track this as privacy addresses change, and remove them with the subnets when appropriate. Hand-wave...

Concept of a role: Think role-based access control. When we talk about access lists (one of the things programmed numerically instead of using names) we are saying we want to allow classes of traffic, which may for example be from a set of prefixes to a set of prefixes using one of a set of IP protocols. When we need to derive the forwarding ACL, we will want to say that we will permit only traffic that goes between things of related roles - mail can go between MUAs and MTAs, financial data can go between financial clients and financial services, and so on. In its most concrete terms, a role specifies a set of applications or data sets that a set of systems might use; it's probably more scalable to think in terms of the class of usage, and use that to mean "any of a set of applications that would be used for that", but ultimately its somehow about applications and data sets. Hand-wavy at the moment, but that's what I'm thinking about.

Concept of route policies: again, route maps are among the things programmed numerically. Again, we want to derive them. Here is can be real simple (IGPs generally pass the trash) or more complex (we may want to aggregate routes between networks, whether they are within our own network, such as OSPF/IS-IS Areas, or between our network and other networks using BGP). The announcement and acceptance policies can build on things they build on now, like community strings etc etc, if appropriate.

The difference between a host and a router is the activity of routing and forwarding. It's tempting to say a node has a binary attribute along those lines. I suspect that it will be more flexible if we say that an interface has a set of zero or more other interfaces that it may forward to. In a host, those sets are all empty; in a router, by default each of those sets normally contains the other IP interfaces on the router. However, it is possible to disallow forwarding between pairs of interfaces at will; this is often used in VRFs and such.

The process of renumbering a network is the process of creating a set of IP interfaces connecting to the same physical interfaces that existing IP interfaces do, creating subnets with the new prefix, attaching the newly-created IP interfaces to the new set of subnets, testing for correctness, and potentially later destroying a subset of the old IP interfaces (which detaches them from the subnets) and destroying the relevant subnets (which detaches them from the interfaces). ACLs and Routing policies get updated by virtue of their roles while that is happening, as does DNS.

If I'm making sense so far, I'll try digging up tools to make this a little more formal.

---

From: Fred Baker <[email-masked]>
Date: Fri, 3 Dec 2010 21:35:29 -0600

On Dec 3, 2010, at 9:24 PM, Fred Baker wrote:

> an IP interface is linked to a set of physical interfaces

or for matter other IP interfaces (tunnels)

---

From: Teco Boot <[email-masked]>
Date: Sat, 4 Dec 2010 10:48:11 +0100

> in with a disparaging remark?

A few hours a day, I sleep :-)  More important: Ran sketched real world 
networks, most of us are facing 48 weeks a year. Or even during the other 
3 weeks @ IETF, with VPN links. Did I ever waved aside such addressing model?

Back to the renumber topic. The scenario Ran sketched has a need
for renumbering every now and then. The private network is constantly in
flux, following mutations in the organization structure or locations.
Also, the public addresses are updated every now and then. The result is,
there is a need for smooth renumbering here. And doable.

Question is: when IPv6 is used in this scenario, is the need for renumbering 
changed? I don't see reasons why not. 

Teco.

---

From: Fred Baker <[email-masked]>
Date: Sat, 4 Dec 2010 05:50:33 -0600

> changed? I don't see reasons why not. 

I would expect that it is the same. In any event, I'm not sure how arguing use cases actually helps. We know that networks need to be reorganized from time to time.

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 4 Dec 2010 09:01:47 -0500

Fred,

That comment is simply rude, to no good effect.
IMHO, an apology to Teco is entirely in order
for that comment.

> You all are talking about various solution ways forward...

The Renum list has not seen emails proposing a new 
architecture; I've rechecked the HTML archives this morning.  
As Brian noted, those are out-of-scope for this list.

This thread is a follow up to a note from me; my note was 
NOT about any "solution way forward", but instead about 
simply documenting an existing IPv4 deployment model that 
many sites use today (and have done for at least a decade).

> to go have a look at ...

As Brian said, this list is not about new architectures,
but about renumbering.  There are ample other lists
where new architectures can be (and are being) discussed.
You routinely post on at least some of those lists.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 4 Dec 2010 09:25:34 -0500

On 04  Dec 2010, at 04:48 , Teco Boot wrote:
> The scenario Ran sketched has a need for renumbering every now and then.
> The private network is constantly in flux, following mutations in the
> organization structure or locations.  Also, the public addresses are
> updated every now and then.
> 
> The result is, there is a need for smooth renumbering here. And doable.

Indeed, the scenario I outlined does need to (partially) renumber
from time to time.  My intended point in fact was that it is 
a deployment model that makes that renumbering MUCH easier 
operationally.

(That last bit above, "makes that renumbering MUCH easier",
is what causes discussion of that common IPv4 deployment model 
to be entirely within-scope for this Renum mailing list.)

Unlike Brian C, I do not view this deployment model as "sad".
Sites have very legitimate reasons to implement site-specific
security policies.  In the model I describe, NAT is chosen 
as a conscious decision to implement the "sessions MUST not be 
initiated from outside" security policy.  Using a NAT is no
different than deploying a Firewall device in the same location.
In the numerous cases that I am familiar with, the Site Border
Router is in fact designed to be border router, stateful
firewall, IPsec VPN endpoint, and (often) also an IDS/IPS.
Various vendors have products in this space; purely as an 
example, a Juniper SRX provides this combination of capabilities. 

Complete end-to-end transparency was a shared universal ideal 
back when the Internet was vastly smaller and more trustworthy.  
In the modern untrustworthy Internet, complete transparency
is at least unsafe and quite often unwise.

> Question is: when IPv6 is used in this scenario, 
> is the need for renumbering changed? 
>    I don't see reasons why not. 

I don't think IPv6 necessarily improves things from a
renumbering perspective.

I suspect the IPv6 equivalent to the model I outlined 
involves ULA addressing within the site and global-scope 
addressing on the exterior interfaces of the Site Border 
Routers (SBRs).  In the near term, IPv4::IPv6 bi-directional
protocol translation might also be part of the picture.

...along those lines, some additional thoughts:

A) Various forms of IPv6 NAT, including but not limited to the 
   one in the "NAT66" I-D, might be implemented in and deployed 
   by those SBRs.  Because one of the common drivers for that 
   deployment model is a security policy prohibiting external 
   nodes from initiating a session with an interior node, 
   one would want those SBRs to include mechanisms that implement 
   that security policy.  Examples of such mechanisms might be 
   traditional state-ful firewalls or traditional state-ful 
   IPv6::IPv6 NAT.

B) I keep expecting to see identity-oriented firewall devices
   to appear with IPv6.  These are obvious to an ordinary
   practioner, IMHO, but I'm not aware of any that are available
   commercially today.  (Perhaps there is a business-model
   challenge in that area ?) In a world where an identity-oriented
   firewall were deployed, the ACL policies would not need 
   to change in the event of a node acquiring a different IPv6
   routing prefix.  So deploying identity-based firewalls could
   significantly reduce the reconfiguration work required 
   when the routing topology of a site needs to change/mutate/evolve.

Cheers,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Dec 2010 07:59:14 +1300

> or for matter other IP interfaces (tunnels)

Well, virtual interfaces in general.

It seems like this approach (with some kind of formal
notation) could capture the 'mathematical' part of a numbering
plan and therefore of a renumbering exercise. Actually, do
any of the existing IP address management packages use a published
formalism of any kind?

   Brian