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

["Fred Baker (fred)" <[e-mail]>]

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.

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.

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
>