Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT

[Philip Matthews <[e-mail]>]

I agree that a business with 1 - 5 employees is likely to go the homenet route.

I was thinking of the somewhat larger business of say 70 - 200 employees, perhaps 2 or 4 locations, and with internal infrastructure. They have a small IT department (perhaps just 1 person), firewalls, perhaps VoIP, perhaps an extranet relationships with suppliers or partners, etc.

I am not an expert in the Enterprise area, so someone else may correct me, but I believe that such companies have not traditionally gotten PI space. Today, they would instead get PA space, use private addresses internally, and use NAT to avoid the renumbering issue when changing providers or to multi-home.

If such a company came to me today and asked "How do I deploy IPv6", then I would be reluctant to say "Get PA space from your provider and use it internally".  I feel this would be doing them a dis-service. 

It seems to me that the ideas that Brian mentions might become options in the future, but they are still in development and are not something that one could recommend to a company today. 

So right now, i see two options that I could realistically recommend to them:
1) Push them to get PI space.  (Would they qualify?  Perhaps someone more familiar with RIR policies can comment.)
2) Use ULA space internally and deploy NPT66.

Is there a viable 3rd option that a company could deploy today?

- Philip


On 2015-10-20, at 22:50 , joel jaeggli wrote:

> On 10/19/15 2:02 PM, Philip Matthews wrote:
>> Brian:
>> 
>> What solution would you recommend today to a small-to-medium-sized
>> enterprise that cannot get PI space and wants the flexibility to
>> easily change providers and possibly multi-home?
> 
> PI space usage is actually about attachment costs, not about the ability
> or inability to obtain it. it's obtainable but not usable if you favor
> low attachment cost.
> 
> Enterprises that favor low attachment costs like my home business favor
> provider managed address ranges, low friction interaction with cloud
> providers, soas for basically applications  and so on);are not going to
> place a great deal of value on source ip addresses, because among other
> things they aren't very stable; I'm sending this email from a train, my
> pan currently has addressing from t-mobile, when I get home that will
> change to comcast, the devices at home, which  can reach from here are
> still on comcast.  for newly initiated connections source address
> selection will tend to favor the network that currently works or if more
> than one exists favor the lower cost/faster  one however you choose to
> weight that .
> 
>> If the enterprise numbers their network internally with PA space,
>> then they need to renumber to change providers. Though this is
>> definitely easier in IPv6 than IPv4, it is still not "easy".  And
>> what about multi-homing?
> 
> if you want a genuinly low attachment cost network al la homenet then
> renumbering for the purposes of useful source selection needs to be
> readily feasible, and fairly transparent. For destination based
> multihoming DNS based GTM, health-checking, low ttls  and other features
> commonly provided as applications are really the rule of the day today
> and that doesn't seem likely to change.
> 
>> - Philip
>> 
>> 
>> On 2015-10-19, at 16:03 , Brian E Carpenter wrote:
>> 
>>>> If ULAs are the only non-Link-Local address available the hosts,
>>>> the enterprise will need to use translation technologies such as
>>>> NPT[RFC6296] or NAT66 to reach the Internet.
>>> 
>>> I think this is still the wrong message. Here's my suggestion:
>>> 
>>> The best approach is to use ULAs for internal communications and 
>>> normal IPv6 addresses for external communications. Running
>>> multiple addresses in this way is a standard feature of IPv6. If
>>> for some reason an enterprise decides to use ULAs as the only
>>> non-Link-Local address available to its hosts, the enterprise will
>>> also need to use the experimental address prefix technology
>>> translation known as NPTv6 [RFC6296] to reach the Internet. Full
>>> address translation (known as NAT66) is never needed for IPv6 since
>>> there is no address shortage.
>>> 
>>> Regards Brian Carpenter
>>> 
>>> _______________________________________________ v6ops mailing list 
>>> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>> 
>> _______________________________________________ v6ops mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>> 
> 
>