Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt

From: [email-masked]
Date: Mon, 14 Nov 2011 22:28:59 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : IPv6 Multihoming without Network Address Translation
	Author(s)       : Ole Troan
                          David Miles
                          Satoru Matsushima
                          Tadahisa Okimoto
                          Dan Wing
	Filename        : draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt
	Pages           : 24
	Date            : 2011-11-14

   Network Address and Port Translation (NAPT) works well for conserving
   global addresses and addressing multihoming requirements, because an
   IPv4 NAPT router implements three functions: source address
   selection, next-hop resolution and optionally DNS resolution.  For
   IPv6 hosts one approach could be the use of NPTv6.  However, NAT
   should be avoided, if at all possible, to permit transparent end-to-
   end connectivity.  In this document, we analyze the use cases of
   multihoming.  We also describe functional requirements and possible
   solutions for multihoming without the use of NAT in IPv6 for hosts
   and small IPv6 networks that would otherwise be unable to meet
   minimum IPv6 allocation criteria.  We conclude that DHCPv6 based
   solutions are suitable to solve the multihoming issues, which
   described in this document.  Nevertheless, we mention that the
   possible needs for NPTv6 in the transition phase to the fully
   deployment of the proposed solutions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt

---

From: Ray Hunter <[email-masked]>
Date: Tue, 15 Nov 2011 19:12:56 +0100

I support this work.

1. I am no fan of NAT. One valid use of NAT that I have seen is to 
guarantee a symmetrical return route for packets that have been routed 
at a remote site using policy based routing (PBR) e.g. Internet offload 
of "bulk" traffic.  A mechanism for routers to be able communicate their 
PBR policy table rules to the local end node should be successful.

But IMHO draft-ietf-6man-addr-select-opt-01 would not seem to be 
adequate, as it does not contain enough high-level application related 
information like something being "expensive" AFAIK. And that leaves a 
hard problem of how to communicate a soft policy that may not be based 
on hard classifiers like bandwidth, but rather dollar cost per megabyte.

2. "In short, while IPv6 facilitates hosts having more than one address 
in the same address scope, the application of this causes significant 
issues for a host from routing, source address selection and DNS 
resolution perspectives"

I still like the "learn by trying" approach of Happy Eyeballs (mentioned 
this back in April) even though it may produce some (small) additional 
burden on the network. One problem again is that start-up metrics 
related to SYN packet performance may not provide appropriate/sufficient 
information to be able to formulate effective or meaningful policy for 
source address/destination address/path selection.

As an extension to the "learn by trying" approach, is there a case for a 
hop-by-hop header option for end nodes to be able to learn path 
characteristics from routers (during session start up)?

I doubt that core routers will ever want to process or add such a header 
option, but I could imagine that a CPE router or end node could be 
configured to tag packets containing a TCP SYN going out of interface A 
as being "cheap" and interface B as being "high latency" based on a 
locally configured administrative option.

That tag could be reflected at the server end back to the client during 
session start up.

I'm thinking of the good old EIGRP metrics as a simple starting point 
[bandwidth, delay, reliability, load, minimum MTU, hop count]. Vendor 
extensions of the tags should of course be possible.

These tags would then be used by the end node to be able to select the 
correct path to use (per application) from the successfully negotiated 
paths.

3. "a function to control every node centrally.  A site administrator or 
a service provider could determine or could have an effect on the 
behavior at their users' hosts."

The draft seems to assume that routers or network managers are all 
knowing, and end nodes and end users are dumb. In a model based on 
mobile handsets connected to alternative (competing) networks, the user 
probably knows more than the service providers about what policy they 
want: think WiFi v 4G. I'd thus prefer a model that was more 
symmetrical, where policy selection and communication of path/topology 
information were orthogonal.

regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Nov 2011 13:00:36 +1300

> 
> 3. "a function to control every node centrally.  A site administrator or a service provider could determine or could have an effect on the behavior at their users' hosts."
> 
> The draft seems to assume that routers or network managers are all knowing, and end nodes and end users are dumb. In a model based on mobile handsets connected to alternative (competing) networks, the user probably knows more than the service providers about what policy they want: think WiFi v 4G. I'd thus prefer a model that was more symmetrical, where policy selection and communication of path/topology information were orthogonal.

That conversation seems to belong in MIF. It's very close to the conversation
in the MIF WG yesterday about draft-chen-mif-happy-eyeballs-extension (which
has the property of apparently needing ESP to work properly).

Regards
   Brian

---

From: Ray Hunter <[email-masked]>
Date: Wed, 16 Nov 2011 09:32:41 +0100

Thanks for the pointer. The slight nuance here is that the end node 
could choose the path based on locally-known application requirements 
(via selecting default router, source, and destination address) all 
going out of the same physical interface (e.g. site Ethernet LAN), but a 
router several hops away (at the site entrance) might be the device that 
actually provides the multiple alternative path characteristics, (e.g. 
based on policy based routing, or having 2 independent ISP routers each 
seeding their own prefixes into the Homenet).

regards,
RayH

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Nov 2011 12:34:51 +1100

Why don't apply some of the techinques from SIDR and have CPE
generate as public key pair use that to validate that it got a
prefix from one ISP and is permitted to use those source address
to the other ISP.

This can be completely automated.  ISP servicing a area just need
to know each others public keys.

This really isn't beyound the hardware capabilities of any CPE
box on the market today.

Lets do source address filtering correctly.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Nov 2011 14:56:55 +1300

I agree that we need a secure automated solution of some kind.

> ISP servicing a area just need

That doesn't solve the general case, because multinationals tend
to be connected to the Internet at very widely separated locations.
So I think the correct statment is

  ISP just need to know each others public keys.

That's a more difficult trust model, but not insoluble (for example,
a trusted public key repository at each RIR).

Regards
   Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Nov 2011 16:50:40 +1100

> a trusted public key repository at each RIR).

I would expect multi-nationals to be able to work around these sort
of restrictions already.  My primary focus is to make it work for
the home / small office.  Bigger customers can usually make this
work today without automation.  Homes and small offices can't because
them man power cost is too high to deal with the volume.

That said I would welcome a solution that scales up to handle any
business that isn't a ISP.

Mark

---

From: Ray Hunter <[email-masked]>
Date: Thu, 17 Nov 2011 10:45:53 +0100

Agreed. Most multinationals I know are already LIRs. They can run BGP to 
the major sites with multiple ISPs and their own PI /32. That's the easy 
bit.

But it isn't just about a few large sites and 2 ISP's. There's also the 
rest of the private corporate network covering 50+ countries + multiple 
(smaller) ISPs to consider.

IMHO I have seen three use cases so far in production today in IPv4 that 
are not really covered in IPv6. To be frank, these current solutions 
seem mainly to be driven by commercial considerations rather than 
technical ones. So if a commercial solution could be found, there 
wouldn't be much resistance to change. Most problems are due to the 
return route, not the outbound one.

1. Home workers, remote branch offices, and SME's that need higher 
availability than a single consumer ISP link, but don't have the 
capability/desire/cash/ISP to run a multihomed BGP AS. Today they can 
use a simple outbound-only load-balancing box, or a specialist VPN box 
that provides 2 GRE/IPSec tunnels via 2 ISPs. The GRE/IPSec solution 
will obviously work in the future, but the load balancer won't.

2. Local Internet break out. Remote corporate site is still connected to 
the corporate network for business/production critical apps, but 
Internet traffic is gatewayed directly into the Public Internet at the 
local site for Internet centric apps like foobarnow.com. Today the local 
site Internet firewall/router can use NAT44 outbound: guaranteeing a 
return route direct to the local site. Most, but not all, Internet 
centric apps are web based, but that would mean installing a proxy on 
every site for IPv6. I see no solution so far for apps that are 
"NAT44-able" but "non-proxy-able" with IPv6. Negotiating ISP routing of 
a single /48 in country X from the PI /32 is unlikely to work in all 
cases. I guess these sites could just use PA space addresses, but then 
you have limited service availability, and potential renumbering issues.

3. Internet offload. Remote corporate site has a main link and an 
Internet connection. Local site router is connected to both and uses 
Policy Based Routing (PBR) to route down the appropriate link. A GRE 
tunnel carries the bulk traffic over the Internet to the regional 
corporate data centre, where it emerges from the tunnel and passes 
through the usual security controls onto the Public Internet. Return 
route to the GRE tunnel is guaranteed via NAT. Otherwise you'd need to 
run PBR on the DC firewall as the Internet tunnel and private corporate 
network are connected to different security zones on the firewall. PBR 
on firewalls doesn't exist so far AFAIK.

In most cases there's multiple hops (and possibly security devices) 
between the end nodes and the point where the alternative paths split.

Mark Andrews wrote:
> <snip>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Nov 2011 00:09:58 +1300

Ray,

> (smaller) ISPs to consider.

Exactly. The small number of biiig multinationals is not an issue.

> will obviously work in the future, but the load balancer won't.

Multipath TCP would handle the load balancing issue (but not of course
for non-TCP traffic). Shim6 would handle failover for all types of flow.
But both of these need both ends to play, which makes deployment sticky.

> you have limited service availability, and potential renumbering issues.

Why? If the local PA link goes down, you'd revert to a slower path
using an address under the PI prefix.

In my experience when I was such a corporate user, I got renumbered whenever
I reconnected my ThinkPad. It was never an issue.

> on firewalls doesn't exist so far AFAIK.

Firewalls aren't routers, but they can have routers glued onto them.

   Brian

---

From: Ray Hunter <[email-masked]>
Date: Thu, 17 Nov 2011 14:06:18 +0100

Inline.

> But both of these need both ends to play, which makes deployment sticky.
Sure.
> I reconnected my ThinkPad. It was never an issue.
The point is that the end node doesn't know which IPv6 source address to 
use for which application and when, because there's no signaling today.

The idea in the draft to distribute an RFC3484 type policy from routers 
to end nodes should theoretically work in this case.

However, the PA prefix could still be up (in RA) and still be valid in 
IA_PD, and the local ISP interface UP, but packet forwarding via the ISP 
link is down, meaning a very slow or incomplete takeover as the end node 
has no indication of upstream failure.

One option would be to ensure that on ISP link failure, the site egress 
router could ensure that all leases and addresses from the PA prefix are 
flushed from the whole site. But there's no flushing mechanism today, 
only timer expiry. Or that a policy update can be pushed to all end 
nodes: not easy.

It's also tricky to deploy in practice right now as end nodes are mobile 
between sites (your Thinkpad moves) and not all end nodes are managed by 
IT (it's your Thinkpad, not mine). So I suspect it'll be tough to write 
a universal RFC3484 policy to cover all end nodes and all cases. Or it 
might become hundreds of lines long. And it probably won't work for 
guests, contractors, or BYOD because of trust issues.

Today you can force these failovers pretty quickly using object tracking 
to simply avoid using the NATted interface at the site router, without 
involving the end nodes at all.

That's why I'm attracted to the "learn by trying" approach: to avoid 
direct policy interactions of routers and end nodes several hops away. 
So intermediate routers could inform end nodes about the characteristics 
of the available end-to-end paths. But end nodes provide the ultimate 
policy of which path to select per application. They also test the end 
to end path before using it, to avoid unhappy eyeballs.
> Firewalls aren't routers, but they can have routers glued onto them.
This is admittedly a corner case and little to do with the IETF 
standards. This is multi-interface firewall where the policies are 
linked to physical interface. Theoretically speaking "gluing" on a PBR 
function would work. But practically speaking, the PBR function has to 
be integrated within the same box as the firewall function, not bolted 
on the outside as an additional router. It's going to be large amounts 
of money to replace / change.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 18 Nov 2011 10:35:11 +0100

>only timer expiry. Or that a policy update can be pushed to all end 

A couple of things. In theory, DHCPv6 allows you push an update to the DHCPv6
client. So, invalidating prefixes and addresses is in theory possible.
The same goes for SLAAC: multicast a RA set the preferred time set to zero
and hosts will avoid that prefix.

Going one step further, routing protocols can be extended to include
information about different default routes (I did it just for RIPng, but it
should not be very hard for other routing protocols as well). If you do that
then the lack of a route default could prompt a router make a prefix not
preferred in RAs. (You want the kinds of 'policy routes' in your routing
protocol anyhow to allow routers to find the right exit for a packet in
more complex situations)

---

From: Ray Hunter <[email-masked]>
Date: Fri, 18 Nov 2011 13:10:58 +0100

Thanks. Got it now. RFC4861 6.3.4 p54 "If the new Lifetime value is 
zero, time-out the prefix immediately."

FYI People in corporate network are already used to dealing with 
multiple candidate default routes via separate protocols + local admin 
distance preference &/or route tagging.

A local RA flush via pio lifetime = 0 triggered by the absence of a 
specific default route tagged per egress router does look feasible.

Pushing an updated policy table to many nodes on a site via DHCPv6 on 
link failure doesn't sound very scalable (or fast). It would also seem 
to require that the DHCPv6 server track who is still active, so it can 
push the info.