Fred Baker (fred) <mailto:[email protected]>
29 October 2014 17:09
On Oct 29, 2014, at 5:05 AM, Ray Hunter<[email protected]> wrote:
Fred Baker (fred) wrote:
On Oct 28, 2014, at 11:28 PM, David Lamparter<[email protected]> wrote:
What I'm personally wondering most in this regard is: to what extent
will larger networks deploy multiple prefixes to the hosts?
Well, define “larger”. Any network that gets a PI prefix is unlikely to deploy
multiple prefixes. The question is at what size network is makes sense to
obtain an AS number and a PI prefix, and use BGP to talk with one’s upstream.
I don't agree with this statement for the following reasons.
Availability: There are many enterprises that have very numerous far-flung
sales-office type locations which do not host any critical data or
applications, but which could benefit from higher availability than that
provided by a single ISP provider (some of which are currently served by a
specialised box offering a Very Small Office Service running dual IPSec tunnels
to a central site, which then performs the break out to the corporate
intranet/Internet)
Latency: There are many sites which could benefit from local Internet breakout
to regional cloud services, where you don't want to suffer the latency
associated with a back haul from an office in Australia to a regional hub in
Hong Kong, or even East coast US to West coast US and back. You'd still also
want some back up via the central breakout if the local breakout failed.
Cost: There are cost savings to be made in many countries where private network
services are still many orders of magnitude more expensive than plain old
Internet. So Internet offload for non-mission-critical traffic can be very
attractive. If you could achieve this via direct host-server connections using
address selection rules or multipath TCP; rather than via PBR, GRE tunnels +
NAT, that would be a lot simpler.
I have a hunch we’re talking past each other. We would agree, but we’re
discussing different cases. I was discussing a case in which a company operates
a single addressing plan. I think you’re discussing a company that operates
multiple addressing plans, one for each of several locations.
Quite possibly.
Cisco might be an example of a “larger” company. We have an IPv6 /32, more
locations than you can shake a stick at, and maybe 20 DMZs, places where our
network interconnects with the Internet. I don’t know exactly what we advertise
or where, but I could imagine that a few of our DMZs advertise the /32 and each
of our DMZs advertises a /40, or something along that line. For us, PI is “duh,
obvious”, and the only case in which we might - *might* - have a second prefix
would be a ULA in a lab.
Well I think it's instructive to look at the current IPv4 unicast
routing table and ask whether replicating this 1:1 into IPv6 is what
enterprises really want.
Multihoming is far more than Internet.
External "3rd Party" networks are often as big as, or even bigger than,
an enterprises own Intranet.
If I look at some customer's current IPv4 routing tables, they contain:
3rd party management companies for IT, speciality partners, per-project
collaboration partners, private cloud, public cloud, merger demerger and
assimilation targets, payment companies, 3rd party management companies
for specialist equipment .... hundreds of prefixes that aren't even
managed by the enterprise in question, and with high churn rates too.
If I ask myself: do all product divisions of the business really want
all of these differing communication requirements to get funneled
through exactly the same handful of 3rd party touchpoints/DMZs to the
outside world on a per region basis, I think the answer would
emphatically be "no".
IMHO Destination based routing (and ensuring balanced/ symmetric return
routes for your own prefixes) imposes unnatural constraints on these
touchpoints/DMZs, compared to what the business expects.
Why do you want to share a route to your crown-jewels /32 prefix, also
used for your sales/finance platform, with someone who just manages some
print servers for one product division on a number of sites via a
dual-redundant 1Mbps link, whilst you have 10Gbps to the Internet? What
happens if this 3rd party print server management company leaks your /32
elsewhere via BGP into another AS? e.g. to another customer where they
also manage their print servers, and who in turn are an important
customer of your own products and want to connect to your front end
sales site (via another higher-speed link).
It remains to be seen whether multiple-prefixes and SADR would help
reduce this complexity, or just shift it around.
e.g. having a different prefix M assigned to a logical management
interface on all print servers managed by party M, in addition to a
prefix C used by the internal customers to connect to the business
interface of the same servers.
You could have a default route for traffic sourced from prefix M
pointing to the server management company via one DMZ to company M, and
a different default route for customers prefix C out of another e.g.
Internet. The management company M would only need a return route to the
specific M prefixes from their network located in your network, and
would not need to learn your /32 C prefix at all. They in turn also
wouldn't have to advertise their crown jewels /32 into your network. And
firewall rules and route filter rules become "allow M to M on one DMZ
gateway", rather than a spaghetti of 10000 individual rules from
prefixes A-Z to prefix C that no-one understands any more.
I do know that trying to encode all of the regions/countries/business
units requirements in the 32 bits available today in IPv6, whilst
attempting to filter using BGP, just doesn't get anywhere near to
expressing the current natural level of business complexity and
availability requirements (assuming /32 RIR allocation and /64 LANs).
And maintaining the related firewall rules and route filters is
currently a nightmare.
I suspect the company you are discussing might have a number of small offices
in as many cities, and as many PA prefixes as it takes. The company might also
have a PI prefix, but I would be surprised if it used the PI prefix in all of
its little offices; if it did, it would essentially use it for internal
traffic, and have some sort of VPN connecting the offices on which it was used.
It would, however, use the PA prefixes from the offices when they need to talk
outside the house. If it is using the PI prefix plus a PA prefix in any given
office, it would depend on RFC 6724’s Rule 8 (longest match) to prefer a PI
address when talking to another address within the prefix, and a temporary
address from PA space otherwise.
In any event, in the context of my comment above, I am thinking of the many
small offices as separate networks. They don’t justify their own PI spaces; the
PI in context acts more like PA from the central corporation than PI in the
traditional sense of the term. They might well get PA from one or more ISPs,
and they might have something akin to PA from their central office or whatever.
Coming back to the question - “would they put multiple subnet prefixes on any
given LAN” - the question really comes back to their requirements and stomach
for complexity. If they require multihoming, such as Jim suggests, I would hope
they would do that. Among my “NAT == Security” customers and SEs, getting them
there requires their network to work well (egress routing being one of many
important parts of that), and a good security solution that doesn’t involve
NAT. Until they have one AND they are convinced, they tell us that the lack of
a NAT solution is a reason to delay deployment. I don’t think that last is
about the number of prefixes around; it’s about security policy and mindset.
Wherever that boundary is, below that networks will use PA prefixes. The
question then becomes: will they multi home?
And I think the answer today is that we don’t know the answer.
This I agree with.
--
Regards,
RayH
--
Regards,
RayH
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
