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

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 19 Oct 2015 11:03:49 -0400

V6ops,

We apologize for the delay from IETF93/Prague on getting discussions out 
for key topics on the draft-ietf-v6ops-design-choices document. We are 
sending out three separate emails to keep the discussion trains split 
for the three topics.

The third item is related to NAT inclusion and related text.

The text is begin updated to ensure that NAT is not recommended per se, 
but will continue to be in document given that is represents a valid 
choice under some real world circumstances which face the readers 
(looking at the full spectrum of readers).

Comments were made at the WG meeting at IETF93/Prague which noted that 
NAT can be avoided, which is true, but those comments may not represent 
the vast number of Enterprises which have different capabilities and/or 
constraints.  Very large Enterprises and the Enterprise Networks for a 
Service Provider are special uses cases where PI space is either easy to 
get, or the network is inherently behind a single SP so PA is not an issue.

Many Enterprise networks have different constraints but still require 
flexibility to support more then one upstream provider, and use of PA 
space may be very limiting and add complexities in the future for the 
Enterprise. A specific use case is an Enterprise that cannot get PI 
space, but wishes the flexibility to easily change providers or 
multi-home; for these Enterprises NTP66 seems to be a reasonable 
choice.  Does anyone have a reasonable alternative which is 
operationally sound.

Its important for the document to consider this as a potential common 
use case for the wider audience which may not be reflected at the WG 
meetings.

regards,

Victor K

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Oct 2015 09:03:36 +1300

> 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

---

From: Philip Matthews <[email-masked]>
Date: Mon, 19 Oct 2015 17:02:13 -0400

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?

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?

- Philip

On 2015-10-19, at 16:03 , Brian E Carpenter wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 20 Oct 2015 09:36:43 +1100

In message <[email-masked]>, Philip Matthews wri
tes:
> 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 provider
> s and possibly multi-home?
> 
> If the enterprise numbers their network internally with PA space, then they n
> eed to renumber to change providers. Though this is definitely easier in IPv6
>  than IPv4, it is still not "easy".  And what about multi-homing?
> 
> - Philip

ULA + GUA(s).  They are going to have to update the DNS when they
changes providers anyway.  The ULA's provide local connection
stability.  The GUA's are for external connectivity.  Use src address
routing to send the traffic out the correct exit route.  This is
what homenet is doing for multi-homed home networks all without
administrator intervention.

Mac's can already use _dns-update._udp SRV records in the DNS to
tell them where to send the TSIG signed updates for their address
records (A and AAAA) in the DNS when they renumber so you don't
even need to be running DHCP{v6} to update the DNS.  There is no
reason other OS vendors can't do the same thing.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Owen DeLong <[email-masked]>
Date: Mon, 19 Oct 2015 17:06:43 -0700

> On Oct 19, 2015, at 15:36 , Mark Andrews <[email-masked]> wrote:
> 
> 

Wow… That’s icky. I’m glad my home is multihomed with BGP.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Oct 2015 13:40:45 +1300

> 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 wh…

Run multiple prefixes. RFC 7157 (and draft-ietf-6man-multi-homed-host).
Once you get your mind round that, renumbering seems easier too.
I'm not trying to say this is completely straightforward. I'm left a bit
frustrated by RFC 6879 and RFC 7010.

   Brian

> .

---

From: Mark Smith <[email-masked]>
Date: Tue, 20 Oct 2015 13:38:55 +1100

On 20 October 2015 at 07:03, Brian E Carpenter
<[email-masked]> wrote:
> [RFC6296] to reach the Internet.

If this is mentioned (and I would prefer it wasn't, because IPv4 NAT
has caused me and the Internet enough trouble), then the limitations
that even stateless NPT imposes on applications must be referenced:

https://tools.ietf.org/html/rfc6296#section-5

> Full address translation (known

---

From: [email-masked]
Date: Tue, 20 Oct 2015 09:36:00 +0200

> frustrated by RFC 6879 and RFC 7010.

it most definitely isn't straight forward.
we've essentially put the responsibility of multi-homing to the host, and you'd need something like MP-TCP or a very smart application (e.g. MOSH). session layer anyone?

I'm running MHMP at home, and I have not found any implementation I'm very impressed with. operationally multi-homing when both links are up works slightly worse than single-homing, and significantly worse when one link is down. not quite the intended outcome. ;-)

cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Tue, 20 Oct 2015 12:22:37 +0200

In your letter dated Tue, 20 Oct 2015 09:36:00 +0200 you wrote:
>we've essentially put the responsibility of multi-homing to the host, 
>and you'd need something like MP-TCP or a very smart application (e.g. 
>MOSH). session layer anyone?

In my experience, when using SLAAC you can do a poor man's multi-homing
by controlling which prefixes are preferred or not.

When a link goes down, make that prefix deprecated. Obviously, existing 
connections will suffer, but if the loss of a link is relatively rare
it works well enough.

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 20 Oct 2015 08:47:51 -0400

Mark,

On 2015-10-19 10:38 PM, Mark Smith wrote:
> If this is mentioned (and I would prefer it wasn't,
So do I, however, that would then not reflect reality in real world 
choices operators / admins need to make.

> because IPv4 NAT
> has caused me and the Internet enough trouble),
Yes, it's been a pain.

> then the limitations
Good reference / point.  We should include this in text and refer to that.

thanks,

Victor K

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 20 Oct 2015 08:54:01 -0400

Philip,

Interesting.  Do you know if this poor man's approach is documented 
anywhere?  In cases like this draft, it would be nice to point to a 
reference if possible.  Trying to describe something like this - in-line 
with text - can be challenging.

Beyond that, the challenge we would face it so get the mass set of 
operators / Enterprises to concisely  understand such an approach, and 
on their own, figure out how to operationalize it.

regards,

Victor K

---

From: Philip Homburg <[email-masked]>
Date: Tue, 20 Oct 2015 15:17:01 +0200

>on their own, figure out how to operationalize it.

I'm not aware of any document that describes this.

I wonder if there is a good text on how to do this with IPv4, i.e. two upstreams
and a NAT box that decides which link to use.

Playing with preferences manually is easy enough on any router that allows 
you to set the preferred time of a prefix.

Document directed at operators could describe how to do it with popular 
routers.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Oct 2015 08:33:19 +1300

> connections will suffer, but if the loss of a link is relatively rare

Yes. I have always regretted that the consensus in the multi6 WG was to
include "Transport-Layer Survivability" as a requirement in RFC 3582.
Since roaming already requires apps to survive transport layer failures,
it's pretty pointless to require it for multihoming failovers.

    Brian

---

From: [email-masked]
Date: Tue, 20 Oct 2015 22:04:40 +0200

> it's pretty pointless to require it for multihoming failovers.

indeed. addresses are ephemeral. unfortunately nothing above layer 3 has come to terms with that.
using address lifetimes as a "routing protocol" is a very bad idea though, in anything but single link networks...

cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Tue, 20 Oct 2015 23:31:14 +0200

In your letter dated Tue, 20 Oct 2015 22:04:40 +0200 you wrote:
>using address lifetimes as a "routing protocol" is a very bad idea 
>though, in anything but single link networks...

It is not a routing protocol. With ingress filtering an address becomes
unavailable when a link goes down because the other link doesn't support
the prefix from which the address was taken.

The routing part is (in theory) a trivial extension to most routing protocols
and fibs.

Distributing which links are up or down and therefor which prefixes are
available or not is probable something for HNCP (or similar). Though in
setups with a single router, it probably can be done by hand as well.

---

From: joel jaeggli <[email-masked]>
Date: Tue, 20 Oct 2015 19:50:44 -0700

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.

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

---

From: [email-masked]
Date: Wed, 21 Oct 2015 12:30:04 +0200

Philip,

> setups with a single router, it probably can be done by hand as well.

in that it would try to convey reachability it would be a routing protocol.

quick brain dump of the issues I see with it:
 - doesn't work in traditional networks (without HNCP) where you don't have a protocol to distribute address lifetimes
 - unclear how it should deal with link flaps
 - only "works" when the directly connected upstream links fails, doesn't deal with the plethora of other failures there might be behind the first upstream
 - unclear how current implementations deal with it

essentially routing != addressing.

I would posit that it doesn't solve the problem, and that we should spend time on solving the problem reasonably completely, instead of wasting it on hacks.

cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Wed, 21 Oct 2015 13:39:02 +0200

>I would posit that it doesn't solve the problem, and that we should 
>spend time on solving the problem reasonably completely, instead of 
>wasting it on hacks.

I think the techincal problems are easy enough to solve. So I'll focus on this
question.

I don't think we can have every small business inject a /48 in BGP. I don't
think ISPs are ready to have a large fraction of their customers bringing
PA space. Let alone do it for almost no extra cost to the customer. So that
option is out, at least for the near future.

At the moment, NAT is quite effective in providing some sort of cheap 
multi-homing for IPv4.

So unless we find a way to provide something better than NAT, people are just
going to implement some kind of NAT for IPv6.

Routing in this context (uplinks to different ISPs, taking into account
source addresses of packets) is mostly a solved problem.

This leaves finding a way to control what source addresses are used. And then
we have a poor man's multi-homing solution.

(DNS is also an issue. I guess all servers are 'in the cloud' these days)

---

From: Philip Matthews <[email-masked]>
Date: Wed, 21 Oct 2015 07:51:58 -0400

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

---

From: [email-masked]
Date: Wed, 21 Oct 2015 14:59:17 +0200

Philip,

> I think the techincal problems are easy enough to solve. So I'll focus on this

I don't think there was a question there. ;-)

for IPv6 multi-prefix multi-homing you have to significantly change your thinking away from the type of "site-multihoming" we do for IPv4. with MHMP the host is in control. sure, the network can offer some help, in indicating that something is amiss with ICMP messages, but where the rubber hits the road is at the host.

in MHMP the host is of course in a much better position to make sensible choices among it's set of candidate SA,DA pairs than what the network is. but we need the host to essentially fulfil the goals of RFC3582.

while you might not think the technical issues are hard, although I encourage you to read the source code of MOSH and MP-TCP, there is a big implementation gap and deployment problem here.

cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Wed, 21 Oct 2015 15:16:33 +0200

In your letter dated Wed, 21 Oct 2015 14:59:17 +0200 you wrote:
>while you might not think the technical issues are hard, although I 
>encourage you to read the source code of MOSH and MP-TCP, there is a big 
>implementation gap and deployment problem here.

I'm not trying deal with Section 3.1.6 of RFC-3582. In a 'traditional'
IPv4 context with multi-homing and NAT this doesn't work. IPv6 with NAT
would also not satisfy the transport layer transparency.

Note that both mosh and mptcp have problems that are non-local. Mosh because it
is yet another security protocol that needs to be validated and deployed.
Mptcp because too many middle boxes destroy end-to-end transparency of the
internet. And of course, mptcp also needs to be deployed.

In contrast, playing with the preferred lifetime of prefixes is completely
local to a site.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 21 Oct 2015 09:05:45 -0700

On 10/21/15 4:51 AM, Philip Matthews wrote:
> 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.
> 
>>> 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
>>> 
>>> 
>>>>> hosts, the enterprise will need to use translation
>>>>> technologies such as NPT[RFC6296] or NAT66 to reach the
>>>>> Internet.
>>>> 
>>>> 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 [email-masked]
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>> 
>> 
> 
>

---

From: <[email-masked]>
Date: Fri, 23 Oct 2015 14:02:14 +0200

3) Use ULA space internally (also for inter-location traffic) and distribute the PA space of whatever provider you are using to the individual hosts for Internet access (thus, each host has at least one ULA, one LLA, and one GUA). This however may cause some firewall rules issues, and in the server environment, autoconfiguration of addresses may be disabled because of security risks.

Holger

-----Ursprüngliche Nachricht-----
Von: v6ops [mailto:[email-masked]] Im Auftrag von Philip Matthews
Gesendet: Mittwoch, 21. Oktober 2015 13:52
An: joel jaeggli
Cc: [email-masked]
Betreff: Re: [v6ops] Follow-up Discussion - draft-ietf-v6ops-design-choices - NAT

- Philip

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

> ability or inability to obtain it. it's obtainable but not usable if 
> you favor low attachment cost.
> 
> 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 .
> 
> 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
>> 
>> 
>>> 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
>>>