On 2009-03-23 08:26, Iljitsch van Beijnum wrote:
On 20 mrt 2009, at 14:40, Brian E Carpenter wrote:
NAT does not offer ANY multihoming benefits whatsoever, in fact, NAT
breaks multihoming because after a rehoming event, the addresses are
translated differently.
It's correct that NAT changeovers break existing sessions. But your
blanket
statement isn't true. NAT-based multihoming has the major benefit that
the number of extra BGP4 routes caused by a multihomed site is exactly
zero.
No. What you're talking about is multiaddress multihoming.
That's true too, but it isn't the same scenario. If it's NAT-based,
the site can use a nice home-made ULA prefix and never has to
think about it again. Multi-prefix based multihoming doesn't
have that convenience factor for the site's IT manager.
See draft-carpenter-renum-needs-work for some of the
consequences.
Then you add NAT to hide the changes to addresses from the hosts. But
IPv6 hosts can work with multiple addresses anyway (well, there's the
ingress filtering issue) so NAT is largely orthogonal to the multihoming.
In fact, there's the exit router selection issue as a result of the ingress
filtering issue. Certainly a site with many exits gets that problem
in any case, but I suggest that it's less acute in the NAT model
because in the end, any exit point will do.
Also, shim6 gives you actual multihoming where sessions survive rather
than the watered down thing where you only get to reestablish new sessions.
Correct. That's why we're standardising shim6. The question isn't there;
it's about what gets deployed.
Also, NAT-based multihoming has value for large international corporate
networks with dozens or hundreds of interconnection points to
the public network. It basically solves their address management
problem when dealing with multiple ISPs in multiple locations. That's
running code today.
People run whatever they can get away with. Doesn't mean it's a good idea.
However, I do agree that it's useful to have stable internal addressing
when external connectivity is subject to change. That is a legitimate
advantage of NAT (66) which we haven't managed to make work without NAT.
We could though, by making sure that ULAs are used for local
connectivity regardless of the external connectivity.
Yes. So how can we persuade IT managers to adopt that as standard
practice?
On 21 mrt 2009, at 16:07, Brian E Carpenter wrote:
Suppose you're operating a large international network with (to take
a random example) IPv4 1/8 as its PI prefix.
You can't just advertise 1/8 in BGP4, because in fact it is split
up into many longer prefixes for various kinds of use and various
geographies.
Then what is the point of having a single prefix?
Mainly historical, or to say it another way, a large corporate
network acquires its own routing swamp over many years. Suppose
you sell a department of the company off to another company, for
example, but the cost of renumbering is considered too high?
(I am not making any of this up, although 1/8 is an example.)
So how do you connect your internal users to the Internet?
Same way as everyone else, return the /8.
Not if you want to do traffic engineering, so that traffic for
the Hong Kong office doesn't enter the Internet in New York.
You have (I'm making this up) 100 different interconnects to the
public Internet around the world, across a variety of ISPs. If you
advertise longer prefixes out of 1/8 through those ISPs, life gets
highly complex if you want multihoming. Certainly you won't be able
to advertise *all* those prefixes through *all* those ISPs, so you'll
need
a complex worldwide management system just for your BGP4 advertisements,
to decide which prefixes are advertised where, and what the desired
backup
paths are. It can be done, but the OPEX is high.
Cost for the community is also high because a single organization puts a
whole bunch of prefixes in the routing table.
Yes
So instead, you run NAT at every ISP connection.
Ok, I said they didn't need the /8 before, but now you've completely
lost me. What is the point of having that prefix now??
None, by now; it's become a private swamp.
Brian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf