Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00

From: Damien Saucez <[email-masked]>
Date: Mon, 1 Oct 2012 09:32:10 +0200

Curtis,

Thank you for the comments.

Our target in this document is to raise the question of multihoming
in personal and/or small/medium enterprise networks, so for now
we were not looking at the mobile device such as smartphones
connected to both 4g and wifi (for this, the multihoming solution
must be implemented directly on the device). We believe that
SOHO would be interested being multihomed but can't afford the
cost of operating multihoming themselves. This is why we suggest
the MSP which is a way to outsource multihoming complexity.

Now, let's go to the technical part. We didn't want to provide
solution so far but we had in mind the following:

1. traffic is tunnelled between the network and the MSP.

2. addresses assigned to devices in the network belong to
the MSP (or at least are advertised by the MSP in BGP) and
then they never change.

3. the MSP box has one "wire" (possibly vie wifi or 3/4G) per
ISP to which the network is connected and each NIC connected
to this "wire" receives addresses dynamically.

Putting these three points together, it means that the gw are
invisible to the devices in the network, that addresses of devices
never change during communications and that traffic always go
through the MSP (even though it is possible to avoid this).

I agree that there is no such thing as the MSP so far, but there
is a bunch of very big service providers that exist today, that are
peering with virtually every significant network and that would
certainly be happy to be the "first hop" for all the communications.

Thank you,

Damien Saucez

On 01 Oct 2012, at 03:21, Curtis Villamizar <[email-masked]> wrote:

> 
> In message <[email-masked]>
> Wassim Haddad writes:
> 
>> Dear all,
>> 
>> We have submitted a problem statement for multihoming in homenet.
>> Comments appreciated!
>> 
>> Regards,
>> 
>> Wassim H.
> 
> 
> Wassim,
> 
> You are proposing a solution, not submitting a problem statement.
> 
> A problem with your solution is that the most common multihoming is
> the mobile device having IP access through both WiFi (via DSL or cable
> or hotspot) and 4G mobile.  In this case the "MSP middlebox" you
> propose would have to be inside the mobile device, which is already
> both one of the gateways and the end host.
> 
> Another problem is the current non-existance of a Multihoming Service
> Provider (MSP)" somewhere out "in the cloud" to replace the source
> address of packets.
> 
> No where in your document does the principle issue with multihoming
> get addressed.  The source address used by the host must be chosen
> somehow by the host or replaced somewhere.  The function of the "MSP
> middlebox" as described is only to redirect outgoing packets.  If the
> source address reflect going through ISP2, and that link goes away,
> then the packets can now go out through ISP1 but the problem of using
> the wrong source address remains.
> 
> If the source address is somehow provided by the MSP, then the traffic
> has to be tunnelled from MSP middlebox to MSP as might be implied by
> the last paragraph in section 4 where it says "In addition, if Gw1 and
> Gw2 provide addresses by the mean of DHCPv6 or RA, addresses at the
> MSPMB will be configured automatically as well".  The word "address"
> barely appears in the draft except for the prior statement and one in
> the intro saying why Shim6 or MPTCP should not be used.  The word
> "tunnel" doesn't appear at all.  The word "source" (as in "source
> address") doesn't appear at all.
> 
> So you don't seem to be proposing a viable solution or perhaps you had
> something to do with tunnelling in mind that you didn't describe at
> all clearly.
> 
> Curtis
> 
> 
>> Begin forwarded message:
>> 
>>> From: "[email-masked]" <[email-masked]>
>>> Subject: I-D Action: draft-haddad-homenet-multihomed-00.txt
>>> Date: September 25, 2012 10:55:38 AM PDT
>>> To: "[email-masked]" <[email-masked]>
>>> Reply-To: "[email-masked]" <[email-masked]>
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> 
>>> 
>>> 	Title           : Multihoming in Homenet
>>> 	Author(s)       : Wassim Haddad
>>>                         Damien Saucez
>>>                         Joel Halpern
>>> 	Filename        : draft-haddad-homenet-multihomed-00.txt
>>> 	Pages           : 7
>>> 	Date            : 2012-09-25
>>> 
>>> Abstract:
>>>  So far, multihoming in Homenet must be supported by the hosts as
>>>  there is no mean to use simultaneously the different Internet Service
>>>  Providers of the "Homenet" without risking flow disruption.  In this
>>>  memo, we describe the problem statement for multihoming in Homenet.
>>>  We also propose a high level solution that answers this particular
>>>  problem.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-haddad-homenet-multihomed
>>> 
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-haddad-homenet-multihomed-00
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 01 Oct 2012 13:33:03 +0100

On 01/10/2012 08:32, Damien Saucez wrote:
> cost of operating multihoming themselves. 

That's a good description of why the IETF designed SHIM6, which requires
no cooperation from any router or ISP and scales well, should cost little
or nothing, and will work for mobile devices too, on two conditions

1. It becomes widely deployed
2. Firewalls allow the SHIM6 extension header.

I don't believe that this is really a topic for homenet, however.

    Brian

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 01 Oct 2012 14:01:55 -0400

In message <[email-masked]>
 
> I don't believe that this is really a topic for homenet, however.

Brian,

Your item #2 might be worth recording somewhere as a requirement if it
is not already in rfc6204bis.  (I didn't look).

If shim6 is the recommendation on the part of homenet as to how to
deal with multihoming in the home, then this is significant and should
be in the framework.

Curtis

---

From: Damien Saucez <[email-masked]>
Date: Mon, 1 Oct 2012 22:09:12 +0200

> I don't believe that this is really a topic for homenet, however.

Well, I don't really like shim6 in this situation because it requires
every host to implement shim6 (is shim6 in a sensor or in an access
controller reasonable?). Also  it is not straightforward with shim6 how
to allow one to manage the devices in its network. In other words,
how to outsource traffic control if shim6 is used? If I remember well
the discussion a few years ago in shim6, the lack of easy
management was sometime pinpointed.

Damien Saucez

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 01 Oct 2012 22:14:57 +0100

Curtis & Damien,

> is not already in rfc6204bis.  (I didn't look).

No. See https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit/
which it might be useful to discuss in Atlanta.

> deal with multihoming in the home, then this is significant and should

It isn't a recommendation as far as I know, but shim6 was designed for use
by small sites unlikely to operate a PI prefix and/or a routing-based
approach to multihoming.

On 01/10/2012 21:09, Damien Saucez wrote:

> controller reasonable?). 

Probably not, but aren't such devices very likely to be gatewayed
by some sort of building services server anyway, which is where
the multihoming comes in? (There was some early work done on proxy
shim6, for such cases.)

> Also  it is not straightforward with shim6 how

Yes, by ISPs who want to use BGP-style traffic engineering for larger
customers. I don't think that applies to homenets. There is also a problem
of exit selection, and although not explicitly aimed at shim6, that issue
also comes up in draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat.

As far as I can tell, multihoming is not mentioned in the homenet charter,
but it is discussed in draft-ietf-homenet-arch, without a clear conclusion.
There is an argument for a specific analysis document on this topic, before
we discuss our favourite solutions.

    Brian

---

From: Ray Hunter <[email-masked]>
Date: Wed, 03 Oct 2012 13:29:53 +0200

I have read the draft and don't see how it advances Homenet.

IMHO If an MSP wants to deploy some tunnel brokers on the Internet to 
terminate what boils down to a pair of GRE tunnels, they can do so 
without the IETF providing any new standards work, and it'll all work 
just fine.

I'd prefer it if people concentrated on 
http://www.ietf.org/id/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt

regards,
RayH

Damien Saucez wrote:
> On 01 Oct 2012, at 03:21, Curtis Villamizar<[email-masked]>  wrote:
>
>> In message<[email-masked]>
>> Wassim Haddad writes:
>>
>>> Dear all,
>>>
>>>> From: "[email-masked]"<[email-masked]>
>>>> To: "[email-masked]"<[email-masked]>
>>>> Reply-To: "[email-masked]"<[email-masked]>
>>>>
>>>>

---

From: Tim Chown <[email-masked]>
Date: Thu, 11 Oct 2012 10:37:20 +0100

> we discuss our favourite solutions.

A homenet arch -05 is about to be published.

As Brian says, there is a brief section in the arch text about multihoming, which we believe captures all that needs to be said. The section tries to describe the architectural implications of different approaches in the context of the architecture goals.  For example, nothing in the architecture should preclude use of shim6, if the hosts support it.

If people have specific comments on 3.2.4 where this is contained, please make them and we can consider those.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Oct 2012 13:37:37 +0100

> If people have specific comments on 3.2.4 where this is contained, please make them and we can consider those.

"  Host-based methods such as Shim6 [RFC5533] have been defined, but of
   course require support in the hosts."

Perhaps you should mention MPTCP here too.

My concern about the whole section is that it leaves things open; it would
be better if the architecture could suggest an immediately available
solution, as well as leaving open alternative solutions for the future.
I think that draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat is the
closest thing we have to an immediately available solution, and it's
in the RFC Editor queue.

Nit: your reference to this I-D in homenet-arch-04 is broken.

  Brian

---

From: Tim Chown <[email-masked]>
Date: Thu, 11 Oct 2012 15:28:04 +0100

> Perhaps you should mention MPTCP here too.

Well, shim6 is just an example, there's no intent to create an exhaustive list.

> closest thing we have to an immediately available solution, and it's

The question then is whether the chairs would like a solution proposed in this section at this point.

If they do, then the above draft is a method that could be applied now/soon, and future work might lead to a homenet routing protocol that allows source and destination based routing (for example).
> Nit: your reference to this I-D in homenet-arch-04 is broken.

Fixed, thanks.

Tim

---

From: Mark Townsley <[email-masked]>
Date: Tue, 16 Oct 2012 11:08:49 +0200

> closest thing we have to an immediately available solution, and it's

draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat seems highly relevant to the work in this group as it is all about what to do when there is more than one router and more than one prefix in a site, specifically with respect to IP assignment and routing. It defines "Multihomed with Multi-prefix" (MHMP) for a host, which is precisely what we would be setting up hosts to be able to do in a homenet with more than one ISP upink with different prefixes. So much the better than its publication is imminent. 

- Mark

---

From: Damien Saucez <[email-masked]>
Date: Fri, 19 Oct 2012 19:01:42 +0200

Regarding all the discussion around this document I think a f2f discussion could help.

Would you please give us a time slot to discuss this during next meeting?

Thank you,

Damien Saucez

---

From: Tim Chown <[email-masked]>
Date: Mon, 22 Oct 2012 14:12:47 +0100

> Would you please give us a time slot to discuss this during next meeting?

Obviously meeting slots are up to the chairs to allocate, but my understanding is that homenet is not attempting to introduce any new multihoming solutions.  But if there's 'cheap wins' those can be taken.

Therefore what seems to be on the table for homenet are:
a) approaches like shim6 which rely on host support.  The homenet arch should not preclude those. They are, on paper, here today.
b) embracing multiple prefixes and solving that challenge with existing tools - see draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.  This could be the 'cheap win'.
c) adding better tools in a new homenet routing protocol, i.e. supporting source *and* destination address based routing. This is most likely some time off.
d) NPT66 (RFC6296), which the homenet arch does not recommend, but see draft-bonica-v6-multihome-03.

I would suggest you look at draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 and see how your approach compares.  Your draft doesn't cite it (and doesn't seem to have any references yet, but I note that may simply be because it's an early version).

Tim

---

From: james woodyatt <[email-masked]>
Date: Mon, 22 Oct 2012 10:43:10 -0700

On Oct 22, 2012, at 06:12 , Tim Chown <[email-masked]> wrote:
> [...]
> [...]

Why is this option still on the table?
Who is arguing for it?
Can we strengthen HOMENET arch to deprecate NPT66 explicitly?

--
james woodyatt <[email-masked]>
core os networking

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Oct 2012 13:47:45 -0400

> Can we strengthen HOMENET arch to deprecate NPT66 explicitly?

Yes, please.

---

From: Tim Chown <[email-masked]>
Date: Mon, 22 Oct 2012 19:07:35 +0100

>> Can we strengthen HOMENET arch to deprecate NPT66 explicitly?

I meant 'on the table' as there is a draft out there (draft-bonica-v6-multihome-03.) describing how to do it.

If there's consensus to explicitly recommend against it in homenet-arch, we can do that.  Personally, I would not like to see NPT66 deployed in home networks.

It would be interesting to hear Fred, Margaret and Ron's views, as the authors of the above.  Perhaps their target is managed enterprises...

Tim

---

From: mike <[email-masked]>
Date: Mon, 22 Oct 2012 11:28:42 -0700

> It would be interesting to hear Fred, Margaret and Ron's views, as the authors of the above.  Perhaps their target is managed enterprises...

I'd say that until we have source address selection that actually works and is widely
deployed, that taking anything off the table is premature. Source address selection
applies just as much on a homenet as anyplace else. Probably even moreso when you
consider corporate VPN's.

Mike

---

From: james woodyatt <[email-masked]>
Date: Mon, 22 Oct 2012 11:57:48 -0700

On Oct 22, 2012, at 11:28 , mike <[email-masked]> wrote:
> applies just as much on a homenet as anyplace else.

Disagree.  My opinion is that the potential for catastrophic damage to the utility of the Internet by the ubiquitous deployment of NPT66 in residential gateways poses too grave a risk for us to continue seriously entertaining it as a viable approach to any of the problems in our ambit.  I would say that it MUST be deprecated by the arch document.

For anyone arguing in favor of using NPT66 in residential gateways, I think it's fair to ask them for solutions to the problem statement in I-D.carpenter-referral-ps <http://tools.ietf.org/html/draft-carpenter-referral-ps> in support of that idea. Referral in IPv4 was badly broken by the introduction of NAT44, and the ubiquitous deployment of NPT66 in residential gateways would repeat the error with IPv6.

I would say HOMENET should not be seriously considering that as an option.  Is there any significant disagreement on that point?  Are there people here who might be willing to stand up and argue that the referral problem is secondary to other objectives well served by deploying NPT66 in home network access routers?  If so, then what are those objectives?  I'm having a hard time understanding what they might be.

> Probably even moreso when you consider corporate VPN's.

Actually, VPN is usually just a special case of MIF, i.e. individual hosts are multihomed, not the whole homenet.  This is a much simpler situation to manage, and solutions for that space are already ubiquitous.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 22 Oct 2012 12:18:51 -0700

> I would say HOMENET should not be seriously considering that as an option.  Is there any significant disagreement on that point?  Are there people here who might be willing to stand up and argue th…

I'm not saying that I like NPT66. I'm saying that IETF has failed to deal with
source address selection such that we're now at the point of address exhaustion
with v4 with nothing working in real devices besides 3484 which is inadequate,
and a lead time of 5+ years before anything is likely to be widely deployed.

So we all know what happens when host devices don't do it: the network in
its own hacked way does it for them. So regardless of whether we like it or
not, NPT and other kinds of network hackery are just an expedient away.
NPT at least doesn't have some of the most egregious sins of NAT.

> Actually, VPN is usually just a special case of MIF, i.e. individual hosts are multihomed, not the whole homenet.  This is a much simpler situation to manage, and solutions for that space are alrea…

No, sorry. Corporate VPN's using v6 and the lack of a coherent source address
selection mechanism causes breakage in bizarre and unpredictable ways.
You are not going to get the results you hope for if your mac uses an ISP prefix
to get back inside the corpro firewall, uRPF if nothing else. SLAAC changes
a lot of things over v4.

Mike

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Oct 2012 12:32:49 +0900

Since earlier on this thread someone was asking for consensus: for the
record, I agree with all James's points.

I think that homenet should declare that NPT66 is not a supported means for
multihoming in home networks.

Yes, there is a multihoming problem, but no, NPT66 is not a solution/ NPT66
is simply moving the problem to the application layer in a half-baked
attempt to solve some, but not all, of it. I'd like to note that both NPT66
and Ron's multihoming draft state clearly that some of the problems, for
example the referral problem, cannot be solved by either solution. We need
to do better than that.

On Tue, Oct 23, 2012 at 3:57 AM, james woodyatt <[email-masked]> wrote:

> Disagree.  My opinion is that the potential for catastrophic damage to the
> utility of the Internet by the ubiquitous deployment of NPT66 in
> residential gateways poses too grave a risk for us to continue seriously
> entertaining it as a viable approach to any of the problems in our ambit.
>  I would say that it MUST be deprecated by the arch document.
>
> For anyone arguing in favor of using NPT66 in residential gateways, I
> think it's fair to ask them for solutions to the problem statement in
> I-D.carpenter-referral-ps <
> http://tools.ietf.org/html/draft-carpenter-referral-ps> in support of
> that idea. Referral in IPv4 was badly broken by the introduction of NAT44,
> and the ubiquitous deployment of NPT66 in residential gateways would repeat
> the error with IPv6.
>
> I would say HOMENET should not be seriously considering that as an option.
>  Is there any significant disagreement on that point?  Are there people
> here who might be willing to stand up and argue that the referral problem
> is secondary to other objectives well served by deploying NPT66 in home
> network access routers?  If so, then what are those objectives?  I'm having
> a hard time understanding what they might be.
>
> Actually, VPN is usually just a special case of MIF, i.e. individual hosts
> are multihomed, not the whole homenet.  This is a much simpler situation to
> manage, and solutions for that space are already ubiquitous.
>
>
> --

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Oct 2012 12:35:19 +0900

On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas <[email-masked]> wrote:

> No, sorry. Corporate VPN's using v6 and the lack of a coherent source
> address selection mechanism causes breakage in bizarre and unpredictable
> ways. You are not going to get the results you hope for if your mac uses an
> ISP prefix to get back inside the corpro firewall, uRPF if nothing else.
> SLAAC changes a lot of things over v4.
>

VPN clients already modify the routing table to ensure traffic going
through the VPN goes through the VPN, to enforce policies around split
tunneling, and so on. Mine even monitors the routing table for changes so
it can act on them.

Can you explain why this behaviour, combined with the "prefer matching
interface" rule in RFC 3484, is not sufficient? If not, then there is no
problem to solve here.

---

From: Ray Bellis <[email-masked]>
Date: Tue, 23 Oct 2012 08:29:59 +0000

> I would say that it MUST be deprecated by the arch document.

The arch document is Informational and contains no RFC 2119 keywords.

Ray

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Oct 2012 17:50:55 +0900

> The arch document is Informational and contains no RFC 2119 keywords.

It can't deprecate it, but it can say that NPT66 is not supported in the
homenet architecture.

---

From: Ray Bellis <[email-masked]>
Date: Tue, 23 Oct 2012 08:54:11 +0000

On 23 Oct 2012, at 09:50, Lorenzo Colitti <[email-masked]>
 wrote:

> It can't deprecate it, but it can say that NPT66 is not supported in the homenet architecture.

Indeed.

Ray

---

From: Tim Chown <[email-masked]>
Date: Tue, 23 Oct 2012 10:46:21 +0100

>> It can't deprecate it, but it can say that NPT66 is not supported in the homenet architecture.

We can capture those sentiments in -07, and use Brian's draft as just one example of why. 

When I said 'it was on the table', that was as something that could well happen. Personally, I would rather see the approach in ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 shorter term, and hope for better support in routing protocols longer term.

BTW, please note that RFC 3484 is now replaced by RFC 6724. It may take some time to adjust :)

Tim

---

From: Michael Thomas <[email-masked]>
Date: Tue, 23 Oct 2012 08:20:07 -0700

On 10/22/2012 08:35 PM, Lorenzo Colitti wrote:
> On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas <[email-masked] <mailto:[email-masked]>> wrote:
>
>     No, sorry. Corporate VPN's using v6 and the lack of a coherent source address selection mechanism causes breakage in bizarre and unpredictable ways. You are not going to get the results you hope for if your mac uses an ISP prefix to get back inside the corpro firewall, uRPF if nothing else. SLAAC changes a lot of things over v4.
>
>
> VPN clients already modify the routing table to ensure traffic going through the VPN goes through the VPN, to enforce policies around split tunneling, and so on. Mine even monitors the routing table for changes so it can act on them.

Routing is irrelevant.

>
> Can you explain why this behaviour, combined with the "prefer matching interface" rule in RFC 3484, is not sufficient? If not, then there is no problem to solve here.

Your ISP gives you 2001:xxxx:: via SLAAC. Your employer gives you 2000::,
but also has 2001:yyyy::. You connect to a server on 2001:yyyy::. Your
3484 v6 stack picks 2001:xxxx for the source address. Hilarity ensues:

1) the packet gets rejected via uRPF
2) the return packet splats against the inside firewall since it's not allowed outside
3) the packet makes it outside unarmored with sad faces from the security team

Mike

---

From: Teco Boot <[email-masked]>
Date: Tue, 23 Oct 2012 18:56:17 +0200

> 3) the packet makes it outside unarmored with sad faces from the security team

Employer should also provide 2001:yyyy::. Or make server accessible via Internet.
BRDP will handle this scenario nicely, also for existing hosts.

Teco

---

From: mike <[email-masked]>
Date: Tue, 23 Oct 2012 10:19:24 -0700

> BRDP will handle this scenario nicely, also for existing hosts.
Presumably, the reason it's behind the corpro firewall is because they don't
want it accessible to the internet at large. I'm not sure if giving each host a
prefix in 2001:yyyy's address space is scalable either for the hosts, the SLAAC
announcements, or just carving up 2001:yyyy's addresses, especially if you have
a large VPN population. I've done that myself, and I have doubts that it's the
right approach.

Mike

---

From: Teco Boot <[email-masked]>
Date: Tue, 23 Oct 2012 19:25:25 +0200

Op 23 okt. 2012, om 19:19 heeft mike het volgende geschreven:

> want it accessible to the internet at large.
OK.

> I'm not sure if giving each host a
I can't get why employer doesn't assign a 2000:: address to the server, other 
than test uRPF filters and get protocol designers crazy :-)

Teco

---

From: Michael Thomas <[email-masked]>
Date: Tue, 23 Oct 2012 10:28:24 -0700

> than test uRPF filters and get protocol designers crazy :-)

They ran of space in the 2000:: allocation? They merged two companies?
There's lots of reasons why a company would have multiple prefixes.

Mike

---

From: james woodyatt <[email-masked]>
Date: Tue, 23 Oct 2012 10:51:56 -0700

> The arch document is Informational and contains no RFC 2119 keywords.

My email to the list was an individual exhortation, and it contained no RFC 2119 keywords.

---

From: james woodyatt <[email-masked]>
Date: Tue, 23 Oct 2012 11:01:37 -0700

> 3484 v6 stack picks 2001:xxxx for the source address. Hilarity ensues:

My IPv6 stack doesn't pick a 2001:xxxx:... address.  When the VPN client connects, it inserts a more-specific host route to 2001:yyyy::/z via the VPN pseudo-interface, so the IPv6 stack picks the interface address assigned by the VPN access concentrator as the source address for application flows to the 2001:yyyy:/z network.

Hilarity does not ensue. Happy faces on the security team.

---

From: Teco Boot <[email-masked]>
Date: Tue, 23 Oct 2012 20:20:53 +0200

Op 23 okt. 2012, om 19:28 heeft Michael Thomas het volgende geschreven:

> They ran of space in the 2000:: allocation?
Ran out a /16 prefix? I can arrange a course on setting up an address allocation scheme.

> They merged two companies?
Yepp, the need for renumbering keeps business going. We have a nice WG for this. Please check their drafts for your scenario, I can't find it. Request to add it?
I think that in general, enterprises do not permit a VPN termination in homenets, where internal traffic is exposed to the Internet. At least, sad faces from the security team.
That brings us back to the MIF use case, with VPN and Internet provisioning domains. And VPN kit on a host.

> There's lots of reasons why a company would have multiple prefixes.
Yes. 

On MIF and VPN termination in the homenet, a host can get addresses from multiple DHCP servers, each with own DNS server(s), just like a normal MIF node. What is the problem? (other than get BRDP in place and a couple of sad faces :-).

Teco

---

From: james woodyatt <[email-masked]>
Date: Tue, 23 Oct 2012 13:20:18 -0700

On Oct 23, 2012, at 12:29 , Michael Richardson <[email-masked]> wrote:
> 
> And the virtual machine on your laptop uses?
> (the current answer: NPT66) 

p1. NPT66 is lousy for this problem; other approaches are proven to work better, but alas I'm not sure I can talk about them here just yet.

p2. laptops are so 20th century... haven't you heard?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 24 Oct 2012 09:27:23 +0900

>> tunneling, and so on. Mine even monitors the routing table for changes so

Sorry, but no. Routing is not irrelevant:

   Rule 5: Prefer outgoing interface.
   If SA is assigned to the interface that will be used to send to D and
   SB is assigned to a different interface, then prefer SA.  Similarly,
   if SB is assigned to the interface that will be used to send to D and
   SA is assigned to a different interface, then prefer SB.

The choice of outgoing interface is a routing decision and thus the routing
table can be used to influence source address selection.

> Your ISP gives you 2001:xxxx:: via SLAAC. Your employer gives you
> 2000::, but also has 2001:yyyy::. You connect to a server on 2001:yyyy::.

You missed the "your employer configures your routing table to point
2000::/64 and 2001:yyyy::/64 to the tunnel interface" step. Your employer
has to configure your routing table today for IPv4 (either a default route
or more-specific routes to private addresses for split tunneling). In IPv6
said employer needs to give you more specifics.

> Your 3484 v6 stack picks 2001:xxxx for the source address.

Nope. A routing lookup tells the kernel that the tunnel interface will be
used to send to that destination, and the RFC3484 stack will pick 2000:: as
the source address due to rule 5 above (note that you don't need to invoke
5.5 in RFC 6724 to make this work; RFC3484 is sufficient).

> Hilarity ensues:

> 3) the packet makes it outside unarmored with sad faces from the security

As James said, none of this happens.

Now - if we want to make this in a routed network where the VPN tunnel is
not terminated on the device itself, then RFC 3484/RFC6724 are not
sufficient. But that problem not substantially different to the "multihomed
with two ISPs problem", which we are trying to solve anyway. I believe this
can be solved properly using source/destination routing.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 24 Oct 2012 09:32:47 +0900

On Wed, Oct 24, 2012 at 2:03 AM, Michael Richardson
<[email-masked]>wrote:

> That solves the routing problem.
> But, what about the naming problem? (whose DNS server do you use?)
>

NPT66 doesn't solve that either, right?

I believe the DNS problem needs to be solved using split DNS at the domain
level, because in the general case that you have more than one VPN there's
no other way to do it.

> Will this solution work if it's more than just your laptop?
> If the VPN terminates on a gateway device?
>

This is a multihoming problem which needs to be solved anyway, and I think
it can be solved using source/destination routing.

> (Or, for instance, what about the virtual machines that you might
> run on your laptop)
>

If the VMs are bridged, it's no different from the multihoming problem. If
they are not, then how are they going to get addresses?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Oct 2012 19:11:31 -0400

james woodyatt <[email-masked]> wrote:
    JW> On Oct 23, 2012, at 12:29 , Michael Richardson
    JW> <[email-masked]> wrote:
    >> And the virtual machine on your laptop uses?  (the current
    >> answer: NPT66)

    JW> p1. NPT66 is lousy for this problem; other approaches are proven
    JW> to work better, but alas I'm not sure I can talk about them here
    JW> just yet.

My example of VMs on a laptop is just to make the
gateway-is-external-to-the-host situation tangible to people who might
think that corporations would never deploy a gateway machine for a
corporate VPN.  (We know that they do, it's in Baker's document...)

    JW> p2. laptops are so 20th century... haven't you heard?

Yup.  The quad-core processor in my the tablet I'm typing this on 
keep suggesting I boot up qemu to I can play minesweeper.

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Oct 2012 19:20:00 -0400

Lorenzo Colitti <[email-masked]> wrote:
    >> That solves the routing problem.  But, what about the naming
    >> problem? (whose DNS server do you use?)
    >> 

    LC> NPT66 doesn't solve that either, right?

    LC> I believe the DNS problem needs to be solved using split DNS at
    LC> the domain level, because in the general case that you have more
    LC> than one VPN there's no other way to do it.

I agree... NPT66 doesn't solve the problem.  If I was forced to build
such a system, I would put a private copy of a stub resolver in my app,
and do DNS requests inside.

In the walled garden situation, however, if I had to hide the AAAA
records (which I think is fundamentally broken, but...), then I'd have
NS delegations from the public DNS into name servers that live in my
walled garden.  So, you could see that my streaming TV system is at 
walledgarden.tvservice.jp, but you couldn't resolve
server23.walledgareden.tvservice.jp.

    >> Will this solution work if it's more than just your laptop?  If
    >> the VPN terminates on a gateway device?
    >> 

    LC> This is a multihoming problem which needs to be solved anyway,
    LC> and I think it can be solved using source/destination routing.

Agreed, which is why I brought it up.  I'm trying to say that since it's
not enough to force the host always get it right, we need to make sure
we have a solution which improves when the host helps, but doesn't
depend upon it.

    >> (Or, for instance, what about the virtual machines that you might

    LC> If the VMs are bridged, it's no different from the multihoming
    LC> problem. If they are not, then how are they going to get
    LC> addresses?

In homenet, if we router where we bridged before, then it would be
routed.  So, my virtualizer should learn to speak homenet routing
protocol.  (go see what nvo3 wants them to do...)

-- 
Michael Richardson
-on the road-

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 25 Oct 2012 09:11:18 +0900

> server23.walledgareden.tvservice.jp.

Solution: from the border router which discovered the DNS entries for
tvservice.jp, inject those DNS servers into the mesh with a tag that they
only be used for tvservice.jp, and pass that around in the routing
protocol. No?

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 25 Oct 2012 15:25:18 +0900

Hi,

> sufficient.

Even in such a case, you can configure manually the policy table on each host
to meet the needs of such source address selection. This mechanism is
included in
both RFC 3484 and RFC 6724.

Moreover, the policy table auto-configuration protocol is now at WGLC state
in 6man.

Thanks.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 25 Oct 2012 06:38:29 -0700

>> not terminated on the device itself, then RFC 3484/RFC6724 are not

That was, in fact, what I was thinking about.
> Moreover, the policy table auto-configuration protocol is now at WGLC state

My only point is that until such an auto-configuration protocol is widely
deployed, there is a real risk that NPT will be deployed as the stopgap that
never goes away. History is on the side of network-based fixes when hosts
can't do the right thing. This working group can snarl all it likes about such
heresies, but it won't alter the outcome if there's a perceived need.

Mike

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Oct 2012 10:20:35 -0400

>> server23.walledgareden.tvservice.jp.

    LC> Solution: from the border router which discovered the DNS entries for
    LC> tvservice.jp, inject those DNS servers into the mesh with a tag that they
    LC> only be used for tvservice.jp, and pass that around in the routing
    LC> protocol. No?

While it's reasonable for my TV settop-box to pay attention to that
extension, why would my laptop or browser know about it?

This really seems invasive to multiple layers of the stack, and I think
it is completely unnecessary.  Zone delegations solve the problem using
existing protocols and existing software.

-- 
Michael Richardson
-on the road-

---

From: Michael Thomas <[email-masked]>
Date: Thu, 25 Oct 2012 09:30:13 -0700

> Hilarity does not ensue. Happy faces on the security team.

As I alluded to in my previous note, this doesn't work unless the vpn is
terminated in host devices. When it's router-router, it fails as I mentioned
because the hosts are clueless. I expect that walled off overlay networks
will be more rather than less prevalent in v6, especially when homenets
are truly visible -- though access controlled -- from the outside which is
pretty untrue today with v4/nat.

Mike

---

From: Teco Boot <[email-masked]>
Date: Fri, 26 Oct 2012 09:29:57 +0200

> pretty untrue today with v4/nat.

More thoughts on this scenario. Assume the company has many branch 
offices (e.g. 1000 small sites, with 2001:xxxx::/48 from ISP), 
where main office has 2000::/48. Each branch office is equipped as 
a homenet, the gear is cheap and just acts as the requirements. It
provides Internet access and VPN to main office and indirect to all 
other branches. Branch office managers set up their homenet equivalent 
to the branch offices. This doubles the number of VPN tunnels. 
For Internet access, nodes on branch offices / homenet configure a 
2001:xxxx:0:mmmm::/64 address. Main office nodes configure 2000:0:0:nnnn::/64. 

We better not send 2000 routes during VPN tunnel setup, for access to
main office and each branch office / homenet. We better configure a 2nd 
address on nodes in the branch offices / homenets, for connectivity 
to nodes in main office or branch office / homenet.
VPN tunnel provides a 2000:0:0:zzz0::/60 prefix to each branch office /
homenet and nodes configure an additional 2000:0:0:zzzz::/64 address for 
access via VPN.

Routing shall forward packets with destination inside the site based
on destination address. For packets outside, routing shall use the source
address. Source addresses in 2001:xxxx::/48 are send to ISP, 
source addresses in 2000:0:0:zzz0/60 are send via VPN tunnel.

IGP / VPN servers in main office may have to handle a bench of prefixes, 
prefix handling on tunnels is kept low.

On source address selection, nodes prefer a 2000:0:0:zzzz::/64 for
destinations within the company, 2001:xxxx:0:mmmm::/64 for elsewhere.

Is this the model we have in mind?

How can source address selection pick the 2001:xxxx:0:mmmm::/64 address for
a destination out of 2000::/16, but not 2000::/48? This is a MIF problem.
Use RFC 6724 policy table Label? Supersede Rule 8?

Now, company acquires another and 2001:yyyy::/48 is connected to the main office.
Branch offices / homenets wants to connect to a 2001:yyyy::/48 address via 
the VPN. I see multiple options:
a) circumvent problems: first renumber acquired company to 2000::/48
b) push a 2001:yyyy::/48 route on VPN tunnels
c) add another VPN prefix on all branch offices / homenets for 2001:yyyy::/48
Option a is the preferred solution, let's pass this to 6renum. Homenet protocols
may help.
Option b makes branch office / homenet IGP more complicated due to route 
redistribution, source address selection and ingress filtering.
Option c makes VPN stack more complicated, due to assignment of multiple 
prefixes.
NPT66 & happy eyeballs could help. But IMHO these are hacks.

Opinions?

Teco

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 26 Oct 2012 16:33:14 +0900

> extension, why would my laptop or browser know about it?

Except that evidence from real deployments (e.g., NTT) is that the
operator's DNS servers are handed out to all boxes on the network. So if
you plug your laptop into the walled garden, that's what you get.

> existing protocols and existing software.

And yet.

---

From: james woodyatt <[email-masked]>
Date: Mon, 29 Oct 2012 10:40:55 -0700

> Opinions?

Seems like a straight-up job for IPsec, which is why RFC 6092 has section 3.2.4 IPsec and Internet Key Exchange (IKE).

---

From: Teco Boot <[email-masked]>
Date: Mon, 29 Oct 2012 21:37:23 +0100

Op 29 okt. 2012, om 18:21 heeft Michael Richardson het volgende geschreven:

> 
>>>>>> "Teco" == Teco Boot <[email-masked]> writes:
>    Teco> More thoughts on this scenario. Assume the company has many branch 
>    Teco> offices (e.g. 1000 small sites, with 2001:xxxx::/48 from ISP), 
>    Teco> where main office has 2000::/48. Each branch office is equipped as 
>    Teco> a homenet, the gear is cheap and just acts as the requirements. It
>    Teco> provides Internet access and VPN to main office and indirect to all 
>    Teco> other branches. Branch office managers set up their homenet
>    Teco> equivalent  
>    Teco> to the branch offices. This doubles the number of VPN
>    Teco> tunnels. 
> 
> A question for clarification: the branch office managers setup the
> homenet at their *HOME* to talk to their office. (The fact that the
> branch office may or may not be a homenet is not relevant)
Ack

> 
> Lest anyone think that the Branch Officer Manager won't know how to do
> this, work in ipsecme right now attempts to automate this kind of
> on-demand partial mesh, and make it work cross-vendor.
I'm not so sure ipsecme and our wg products are compatible.

Teco

> 
> -- 
> Michael Richardson <[email-masked]>, Sandelman Software Works 
> 
>