Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)

[Ray Hunter <[e-mail]>]

> Fred Baker (fred) <mailto:[e-mail]>
> 29 October 2014 17:09
> On Oct 29, 2014, at 5:05 AM, Ray Hunter<[e-mail]>  wrote:
>
>> Fred Baker (fred) wrote:
>>> On Oct 28, 2014, at 11:28 PM, David Lamparter<[e-mail]>   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