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

joel jaeggli <joelja@bogus.com> Wed, 21 October 2015 16:05 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBA51B29E0 for <v6ops@ietfa.amsl.com>; Wed, 21 Oct 2015 09:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWvSibROs1zH for <v6ops@ietfa.amsl.com>; Wed, 21 Oct 2015 09:05:55 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF91C1B29DE for <v6ops@ietf.org>; Wed, 21 Oct 2015 09:05:54 -0700 (PDT)
Received: from mb.local (c-73-158-58-32.hsd1.ca.comcast.net [73.158.58.32]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t9LG5qsc079927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 21 Oct 2015 16:05:53 GMT (envelope-from joelja@bogus.com)
To: Philip Matthews <philip_matthews@magma.ca>
References: <56250655.2040701@jvknet.com> <56254C98.2010501@gmail.com> <75421D8D-362D-4D47-AB56-B8CB7639CC51@magma.ca> <5626FD84.1050101@bogus.com> <8A1B7AC2-AC0A-4553-946C-ED743450DD81@magma.ca>
From: joel jaeggli <joelja@bogus.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <5627B7D9.2010003@bogus.com>
Date: Wed, 21 Oct 2015 09:05:45 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Thunderbird/42.0
MIME-Version: 1.0
In-Reply-To: <8A1B7AC2-AC0A-4553-946C-ED743450DD81@magma.ca>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="tNJG5FB6AbBkpQ54okUljOmaACTL1fLM2"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/rXHd5D1kHbTQCupUXwBOGRSNMdc>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Oct 2015 16:05:57 -0000

On 10/21/15 4:51 AM, Philip Matthews wrote:
> 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.

so I oddly enough work in an enterprise that's of a somewhat similar
scale (200ish)...

The bigger office it has a gig link from level3 a pair of firewalls, a
pa v4 prefix and a pa v6 prefix. When we moved from down the road we had
building supplied link to XO (with no v6). the v4  is natted, the v6 is
not. the internal structure involves a total of 4 subnets of which three
are dual stacked.

The smaller offices are comcast business links (in the us) or as
appropriate in-country providers.

We obviously do have PI space, (the business is a CDN after all) we
don't use it in conjuction with the offices, whose networks exist to
provide connectivity to the people in them, not to support the core
tooling of the enterprise, which lives in colocation facilities, cloud
providers, and SOAS applications.

> 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.

Some enterprises have large investment in buildings hardware and
supporting  infrastructure in service to the core mission of the
enterprise (think of hospitals, airports, factories, large mining
operations and so on). these are going to favor heavily structured
network deployments. Those are not likely well suited to fluid
renumbering. in others numbering should be of little actual consequence
because it doesn't figure centrally in the infrastrcture.


> 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 v6ops@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>> 
>>> 
>>> _______________________________________________ v6ops mailing
>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>> 
>> 
> 
>