Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
Hi All, I support Ray position. Maybe this drafts solves some situation but I believe it might bring more problems than solutions. regards, Alejandro, On 10/3/12, Ray Hunter v6...@globis.net wrote: 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: 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 Villamizarcur...@occnc.com wrote: In message08880dcf-fec8-4b52-8db4-0300ac1ec...@ericsson.com 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: internet-dra...@ietf.orginternet-dra...@ietf.org Subject: I-D Action: draft-haddad-homenet-multihomed-00.txt Date: September 25, 2012 10:55:38 AM PDT To: i-d-annou...@ietf.orgi-d-annou...@ietf.org Reply-To: internet-dra...@ietf.orginternet-dra...@ietf.org 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
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On Oct 26, 2012, at 24:29 , Teco Boot t...@inf-net.nl wrote: 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). -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
Op 29 okt. 2012, om 18:21 heeft Michael Richardson het volgende geschreven: Teco == Teco Boot t...@inf-net.nl writes: Teco More thoughts on this scenario. Assume the company has many branch Teco offices (e.g. 1000 small sites, with 2001:::/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 mcr+i...@sandelman.ca, Sandelman Software Works ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
Op 25 okt. 2012, om 18:30 heeft Michael Thomas het volgende geschreven: On 10/23/2012 11:01 AM, james woodyatt wrote: On Oct 23, 2012, at 08:20 , Michael Thomas m...@mtcc.com wrote: On 10/22/2012 08:35 PM, Lorenzo Colitti wrote: 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::: via SLAAC. Your employer gives you 2000::, but also has 2001:::. You connect to a server on 2001:::. Your 3484 v6 stack picks 2001: for the source address. Hilarity ensues: My IPv6 stack doesn't pick a 2001::... address. When the VPN client connects, it inserts a more-specific host route to 2001:::/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::/z network. 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. More thoughts on this scenario. Assume the company has many branch offices (e.g. 1000 small sites, with 2001:::/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::0:::/64 address. Main office nodes configure 2000:0:0:::/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:::/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:::/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:::/64 for destinations within the company, 2001::0:::/64 for elsewhere. Is this the model we have in mind? How can source address selection pick the 2001::0:::/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:::/48 is connected to the main office. Branch offices / homenets wants to connect to a 2001:::/48 address via the VPN. I see multiple options: a) circumvent problems: first renumber acquired company to 2000::/48 b) push a 2001:::/48 route on VPN tunnels c) add another VPN prefix on all branch offices / homenets for 2001:::/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 Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On Thu, Oct 25, 2012 at 11:20 PM, Michael Richardson mcr+i...@sandelman.cawrote: 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? 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. 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. And yet. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
Hi, 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. 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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On 10/24/2012 11:25 PM, Arifumi Matsumoto wrote: Hi, 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. That was, in fact, what I was thinking about. 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
Lorenzo Colitti lore...@google.com wrote: In the walled garden situation, however, if I had to hide the 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. 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- pgpVZmoIkorRC.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On 10/23/2012 11:01 AM, james woodyatt wrote: On Oct 23, 2012, at 08:20 , Michael Thomas m...@mtcc.com wrote: On 10/22/2012 08:35 PM, Lorenzo Colitti wrote: 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::: via SLAAC. Your employer gives you 2000::, but also has 2001:::. You connect to a server on 2001:::. Your 3484 v6 stack picks 2001: for the source address. Hilarity ensues: My IPv6 stack doesn't pick a 2001::... address. When the VPN client connects, it inserts a more-specific host route to 2001:::/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::/z network. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
RJ Atkinson rja.li...@gmail.com wrote: RJ It might be useful for James Woodyatt's notes about these RJ technical issues to get written up as an Informational RFC, to RJ help document the technical issues/operational issues for any RJ new participants here (and more generally for IETF newcomers who RJ might not immediately grasp the issues). ...+1 RJ PS: Yes, I understand this won't stop a vendor from shipping RJ NPT66, but we can at least make it clear that NPT66 has RJ significant technical limitations and unresolved issues, so is RJ NOT part of the Home Net solution set. more importantly, if said document was written from a SHOULD point of view rather than a strict SHOULD NOT, it might be possible for a large buyer of either equipment or services to use it as part of an RFP. This could be a media ISP procuring settop boxes, or a hospital procuring digital TV services, or a government department procuring a managed VPN service, etc. -- Michael Richardson -on the road- pgpiWjW2vWsMi.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
Lorenzo Colitti lore...@google.com 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 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 run on your laptop) 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- pgpdWVDCWgYCs.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On Thu, Oct 25, 2012 at 8:20 AM, Michael Richardson mcr+i...@sandelman.cawrote: In the walled garden situation, however, if I had to hide the 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. 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? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On 22 Oct 2012, at 19:57, james woodyatt j...@apple.com wrote: I would say that it MUST be deprecated by the arch document. The arch document is Informational and contains no RFC 2119 keywords. Ray ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On 23 Oct 2012, at 09:50, Lorenzo Colitti lore...@google.com wrote: It can't deprecate it, but it can say that NPT66 is not supported in the homenet architecture. Indeed. Ray ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On 23 Oct 2012, at 09:54, Ray Bellis ray.bel...@nominet.org.uk wrote: On 23 Oct 2012, at 09:50, Lorenzo Colitti lore...@google.com wrote: It can't deprecate it, but it can say that NPT66 is not supported in the homenet architecture. Indeed. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On 10/22/2012 08:35 PM, Lorenzo Colitti wrote: On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas m...@mtcc.com mailto:m...@mtcc.com 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::: via SLAAC. Your employer gives you 2000::, but also has 2001:::. You connect to a server on 2001:::. Your 3484 v6 stack picks 2001: 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
Op 23 okt. 2012, om 17:20 heeft Michael Thomas het volgende geschreven: On 10/22/2012 08:35 PM, Lorenzo Colitti wrote: On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas m...@mtcc.com mailto:m...@mtcc.com 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::: via SLAAC. Your employer gives you 2000::, but also has 2001:::. You connect to a server on 2001:::. Your 3484 v6 stack picks 2001: 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 Employer should also provide 2001:::. Or make server accessible via Internet. BRDP will handle this scenario nicely, also for existing hosts. Teco Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On 10/23/2012 10:25 AM, Teco Boot wrote: I'm not sure if giving each host a prefix in 2001:'s address space is scalable either for the hosts, the SLAAC announcements, or just carving up 2001:'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. 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 :-) 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On Oct 23, 2012, at 01:29 , Ray Bellis ray.bel...@nominet.org.uk wrote: On 22 Oct 2012, at 19:57, james woodyatt j...@apple.com wrote: I would say that it MUST be deprecated by the arch document. 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. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On Oct 23, 2012, at 08:20 , Michael Thomas m...@mtcc.com wrote: On 10/22/2012 08:35 PM, Lorenzo Colitti wrote: 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::: via SLAAC. Your employer gives you 2000::, but also has 2001:::. You connect to a server on 2001:::. Your 3484 v6 stack picks 2001: for the source address. Hilarity ensues: My IPv6 stack doesn't pick a 2001::... address. When the VPN client connects, it inserts a more-specific host route to 2001:::/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::/z network. Hilarity does not ensue. Happy faces on the security team. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
Op 23 okt. 2012, om 19:28 heeft Michael Thomas het volgende geschreven: On 10/23/2012 10:25 AM, Teco Boot wrote: I'm not sure if giving each host a prefix in 2001:'s address space is scalable either for the hosts, the SLAAC announcements, or just carving up 2001:'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. 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 :-) 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 Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
I agree with Lorenzo Colitti, Ted Lemon, James Woodyatt, and various others about the adverse operational impacts of using NPT66. So I also agree that the Home Net Architecture document (and any other applicable Home Net documents) ought to clearly indicate that NPT66 is NOT part of the HomeNet Architecture and is NOT a recommended approach. It might be useful for James Woodyatt's notes about these technical issues to get written up as an Informational RFC, to help document the technical issues/operational issues for any new participants here (and more generally for IETF newcomers who might not immediately grasp the issues). Yours, Ran PS: Yes, I understand this won't stop a vendor from shipping NPT66, but we can at least make it clear that NPT66 has significant technical limitations and unresolved issues, so is NOT part of the Home Net solution set. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On Wed, Oct 24, 2012 at 12:20 AM, Michael Thomas m...@mtcc.com wrote: On 10/22/2012 08:35 PM, Lorenzo Colitti wrote: On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas m...@mtcc.com mailto: m...@mtcc.com 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. 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. 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::: via SLAAC. Your employer gives you 2000::, but also has 2001:::. You connect to a server on 2001:::. You missed the your employer configures your routing table to point 2000::/64 and 2001:::/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: 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: 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 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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On Wed, Oct 24, 2012 at 2:03 AM, Michael Richardson mcr+i...@sandelman.cawrote: 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? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On Oct 22, 2012, at 06:12 , Tim Chown t...@ecs.soton.ac.uk wrote: Therefore what seems to be on the table for homenet are: [...] d) NPT66 (RFC6296), which the homenet arch does not recommend, but see draft-bonica-v6-multihome-03. [...] Why is this option still on the table? Who is arguing for it? Can we strengthen HOMENET arch to deprecate NPT66 explicitly? -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On Oct 22, 2012, at 1:43 PM, james woodyatt j...@apple.com wrote: Can we strengthen HOMENET arch to deprecate NPT66 explicitly? Yes, please. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On 10/22/12 11:07 AM, Tim Chown wrote: On 22 Oct 2012, at 18:47, Ted Lemon mel...@fugue.com wrote: On Oct 22, 2012, at 1:43 PM, james woodyatt j...@apple.com wrote: Can we strengthen HOMENET arch to deprecate NPT66 explicitly? Yes, please. 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... 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On Oct 22, 2012, at 11:28 , mike m...@mtcc.com wrote: 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. 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. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On 10/22/2012 11:57 AM, james woodyatt wrote: On Oct 22, 2012, at 11:28 , mike m...@mtcc.com wrote: 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. 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. 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. 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
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 j...@apple.com 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. 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. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
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 On 11 Oct 2012, at 11:37, Tim Chown t...@ecs.soton.ac.uk wrote: On 1 Oct 2012, at 22:14, Brian E Carpenter brian.e.carpen...@gmail.com wrote: 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
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: 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 Villamizarcur...@occnc.com wrote: In message08880dcf-fec8-4b52-8db4-0300ac1ec...@ericsson.com 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: internet-dra...@ietf.orginternet-dra...@ietf.org Subject: I-D Action: draft-haddad-homenet-multihomed-00.txt Date: September 25, 2012 10:55:38 AM PDT To: i-d-annou...@ietf.orgi-d-annou...@ietf.org Reply-To: internet-dra...@ietf.orginternet-dra...@ietf.org 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
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On 01 Oct 2012, at 14:33, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 01/10/2012 08:32, Damien Saucez wrote: 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. 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. 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 Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
Curtis Damien, On 01/10/2012 19:01, Curtis Villamizar wrote: In message 50698d7f.5000...@gmail.com Brian E Carpenter writes: On 01/10/2012 08:32, Damien Saucez wrote: 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. 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 Brian, Your item #2 might be worth recording somewhere as a requirement if it 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. 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. 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: 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?). 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 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
