I-D Action:draft-azinger-scalable-addressing-00.txt

[S.P.Zeidler]

Thus wrote Fred Baker (fred at cisco.com):

> On Sep 26, 2010, at 1:26 PM, S.P.Zeidler wrote:
> 
> > If I could get the wish fairy to attend, I'd get RFC1493 addresses
> > internally, and a stateless prefix NAT of whatever kind by the
> > firewalls that lets the firewalls make sure that routing works as
> > it should. (ILNP sounds fine but has the drawback that it only allows
> > locator changes when the responder does ILNP too).
> 
> 1493 is managed objects for bridges. Do you mean ULAs (RFC 4193)?

augh, what a stupid typo. Yes, of course ULA. :)

> So - you would be in favor of something like http://tools.ietf.org/html/draft-mrw-behave-nat66

I like ILNP better in principle (also because I can see an immediate use
for any laptop with both wireless and wired connectivity :), but
I need something 'soonish' that doesn't require more of the hosts than
What Everybody Does (tm), and I'm pretty sure having two dozen routes
announced to hosts via router advertisements is going to be on the
eccentric side. It's just a question in how many variants of equipment
you need to know and control bugs in little used code paths.

The practical solution (in the absence of NAT) is to go "there are some
hosts that have the proper statically assigned addresses and routes to
specific destinations because there is a business reason that was
sufficiently known in advance to give them that, and there are proxies. 
Everything else moves inside the local network and the VPNs or is out of
luck.", ie significantly less connectivity.

The slightly impractical but quite possible solution is to ignore the
absence of IETF guidance regarding prefix translation and Just Do It,
since the outside world doesn't need to know about and cooperate on it
for a lot of cases.

> That particular model has a down side, in that to make the checksums work end to end we update the prefix or the EID, which makes session switchover less seamless. But it requires no change to the host.

Switchover in case of link failure will be 'traumatic' since the outside
prefix changes. That's always annoying but not necessarily a big issue.
Switchover from one router/firewall to the other should not change the
translation seen if the implementation of the prefix translator is the same,
right? I'm likely not getting what you are referring to.

regards,
	spz
-- 
spz at serpens.de (S.P.Zeidler)