[rrg] solution strategies, nat? Herrin's Architectural Principle

[Robin Whittle]

Ran Atkinson wrote:

>>> (NAT/NAPT or LocatorRewriting or pick a another name) performed
>>> inside a site's border router can enable a site to multi-home
>>> effectively without any de-aggregation (i.e. without any impact on
>>> the DFZ RIB or DFZ FIB).  Existing mechanisms that enable
>>> distributed firewalls to share session state would clearly also work
>>> to share NAT session state among a set of site border routers, if
>>> that were desired.

Scott Brim wrote:

>> Multihoming on different providers?  If an endpoint appears to have
>> two different addresses due to being NATted onto two different
>> providers, and routing changes so that packets switch from flowing
>> through one provider to flowing through the other one, connections
>> break.

Brian Carpenter wrote:

> Certainly. So if you were product manager for a highly reliable
> distributed application, I'm sure you would insist that it was
> coded to detect permanent transport failures and try alternative
> addresses. That may not be elegant computer science but it's one
> way that the Internet routes around damage.

Tony Li wrote:

> And that again results in trying to fix the routing architecture at
> layers 7 and 8.  You'll pardon me if I don't find that a
> particularly satisfying 'solution'.

I agree.  Furthermore, it would be in violation of Herrin's
Architectural Principle:

   http://www.irtf.org/pipermail/rrg/2008-December/000620.html

     Any problem can be solved at the application layer for a single
     application. Architectural solutions solve the problem at a
     lower layer so that it stays solved for *all* applications.

This is a concise statement of good design principles which have long
been known in many fields - including networking, software, building
design and urban planning.

  - Robin