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

On 2010-12-04 03:45, RJ Atkinson wrote:
> 
> 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.

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

> 
> 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. site-11@organisation.foo) 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
> 
> 
> _______________________________________________
> renum mailing list
> renum@ietf.org
> https://www.ietf.org/mailman/listinfo/renum
> 