Re: [homenet] prefix assignment on home networks
Most major wireline deployments provide /60, /56 or /48. Examples: free.fr, KDDI, ATT. Exceptions are RCS+RDS (working on shorter prefixes) and some North American cable operators, which AIUI are crippled by sucky CPEs that fail to do anything useful when they receive more than a /64. On Thu, Nov 15, 2012 at 2:27 AM, Randy Turner rtur...@amalfisystems.comwrote: Have their been any ISPs that have come forward to discuss their consumer IPv6 allocation plans? I don't think we should wrap ourselves around a model that says, yeah, we need multiple /64s for consumers because that's the way a particular protocol works (SLAAC). Maybe we need another method. One /64 for a home network seems like overkill regarding address space utilization -- A /32 would be overkill. I know some folks think we have more address space than we'll ever use, but gee…. Randy On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote: On Nov 14, 2012, at 3:31 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 14/11/2012 02:34, Randy Turner wrote: I was thinking that, in an effort to reduce scope to something we can deal with for now, that a /64 would be big enough It simply isn't, because it doesn't allow subnetting in the home/car/small office or whatever. I don't see the point in working on the /64 case—if that's all we're trying to accomplish, we've already accomplished it. The interesting work Homenet is doing is in fact trying to solve the prefix distribution and automatic setup problem. It's true that this is a hard problem. It's also true that if we don't specify a solution, people will attempt to solve it in their own ways. And if they do that, we will wind up in the situation that Jim found himself in with his broken box with its own built-in DHCP server. BTW, a little more on that topic: the reason that two DHCP servers on the same wire broke Jim's network in a flaky way is that IPv4 doesn't handle the multi-homing case. IPv6 deliberately places the multi-homing case in-scope. This creates a bit of a problem for legacy apps that do not support multi-homing, but it also creates the winning situation that if one device is advertising a provisioning domain that doesn't work, applications that do correctly handle multi-homing will simply use a different provisioning domain. ___ 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
James, However notionally easy this problem is to address, I imagine that practical matters, at some point, must rise to the top of the pile of points to consider. Those hosts are broken. They can't work in a multi-homed environment. Those hosts are not broken. They work fine in single-homed edge networks, which are ubiquitous. The deployment of multiple heterogenous default routers with hosts that expect networks to be single-homed is what breaks the network. given dual stack. all hosts are multi-homed. multiple prefixes and multiple default routers have been part of the IPv6 design from day 1. Also, rule 5.5 of RFC 6724 is inadequate. Hosts that implement it should work better than those that don't because new flows created after the primary default router becomes unreachable should automatically go to the next available default router, but existing flows will still be broken in the absence of the kind of coordination I described previously. arguing from a standards perspective (not what implementations do). I don't think any of our documents describe a primary default router. given we have: RFC4861, RFC4311, RFC4191 and RFC6724 what is missing? combined with happy eyeballs of course. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
Also, rule 5.5 of RFC 6724 is inadequate. Hosts that implement it should work better than those that don't because new flows created after the primary default router becomes unreachable should automatically go to the next available default router, but existing flows will still be broken in the absence of the kind of coordination I described previously. Well, this is just wrong. I didn't think this through completely. Rule 5.5 of RFC 6724 *is* inadequate, but not for precisely the reason I describe above. It would help, but Rule 3 overrides it, and dragons await the unwary sailor who doesn't keep synchronized clocks. rule 3 deprecated addresses. how does that apply? cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
Ole, On 16/11/2012 09:28, Ole Trøan wrote: James, However notionally easy this problem is to address, I imagine that practical matters, at some point, must rise to the top of the pile of points to consider. Those hosts are broken. They can't work in a multi-homed environment. Those hosts are not broken. They work fine in single-homed edge networks, which are ubiquitous. The deployment of multiple heterogenous default routers with hosts that expect networks to be single-homed is what breaks the network. given dual stack. all hosts are multi-homed. multiple prefixes and multiple default routers have been part of the IPv6 design from day 1. Also, rule 5.5 of RFC 6724 is inadequate. Hosts that implement it should work better than those that don't because new flows created after the primary default router becomes unreachable should automatically go to the next available default router, but existing flows will still be broken in the absence of the kind of coordination I described previously. arguing from a standards perspective (not what implementations do). I don't think any of our documents describe a primary default router. given we have: RFC4861, RFC4311, RFC4191 and RFC6724 what is missing? combined with happy eyeballs of course. I think a unified explanation of the best current practice is missing. Also there is that MAY in 6724 that I mentioned earlier, which seems weak in view of the discussion here. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On 14/11/2012 22:44, james woodyatt wrote: On Nov 14, 2012, at 13:34 , Mikael Abrahamsson swm...@swm.pp.se wrote: I've always seen it to be solved via some kind of source based routing automatically discovered between the ISP routers. My point is that it isn't sufficient to handle this problem at just the routers. At a minimum, the *hosts* need to be told which default router to use with each source prefix. Of course. I suggested this when MIF started out, and it's a MIF issue still. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On Thu, Nov 15, 2012 at 9:16 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 14/11/2012 22:44, james woodyatt wrote: On Nov 14, 2012, at 13:34 , Mikael Abrahamsson swm...@swm.pp.se wrote: I've always seen it to be solved via some kind of source based routing automatically discovered between the ISP routers. My point is that it isn't sufficient to handle this problem at just the routers. At a minimum, the *hosts* need to be told which default router to use with each source prefix. Of course. I suggested this when MIF started out, and it's a MIF issue still. The hosts do already select the correct router depending on the prefix. They're tied together. An RA contains a prefix and router address. That's what the host keeps in memory. If it's two RA's one router becomes default, the other more specific. The host/applications will also only use one prefix at a time, thus always send the packets down the correct path. In my experience it was always the same prefix, the one that got registered first (if no preference was setup in the advertising router). If the host is connected via two or more interfaces (so we're in MIF area now), there will always be one preferred prefix, and interface, and the outgoing routing will work. If applications are able to chose a specific prefix (e.g. VPN) they usually implement some source routing on the host anyways, and send the packets to the router registered with that prefix. If you have an application listening for incoming connections, then it's important that the application is smart enough to use the address on which the incoming connection arrived as source address, and not the default one which might be on a different prefix to avoid asynchronous communication. As far as I know this is already common practice. So I don't really see a problem here, unless you want to do some fancy load sharing and play ping pong with source addresses. If there's only one interface which connects to a multihomed router, the principle is the same, but the multihomed router must be able to perform source address routing, and forward the packets down the right path. And this is something I'm not too sure about routers can currently do. Mat ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
My point is that it isn't sufficient to handle this problem at just the routers. At a minimum, the *hosts* need to be told which default router to use with each source prefix. Right now the only mechanism that comes close to doing that is ICMPv6 Redirect, which isn't suitable for addressing this problem. This is at least notionally a very easy thing to do, since the source address they are using is in a prefix that they configured on the basis of a router advertisement. When would it make sense to send a packet with that source address to any router other than the one that advertised that prefix? exactly. that's rule 5.5 in RFC6724. when there are intermediate routers between the host and the border routers the routers need to use SADR (source address dependent routing). all we can do in the IETF is to write documents. I think RFC6724 is sufficient, but please correct me if I'm wrong. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On Nov 14, 2012, at 10:41 PM, james woodyatt j...@apple.com wrote: However notionally easy this problem is to address, I imagine that practical matters, at some point, must rise to the top of the pile of points to consider. Those hosts are broken. They can't work in a multi-homed environment. Millions of hosts is very close to zero. Do you want to wait to solve this problem until there are billions? Most of those hosts are Macs, iOS devices and Android devices, which can be upgraded easily and are upgraded frequently (at least according to the stats I follow). So please just fix this bug in iOS and MacOS, instead of arguing that the situation is hopeless. We are building a network protocol suite for the future, not the present. IPv4 was broken in various ways when it was at the stage of deployment IPv6 is at. Measures were not taken to solve some of its problems in the IETF, and as a consequence ugly hacks were done in the field to work around these problems. It is not our job to prognosticate about what might get deployed. It is to try to figure out what should get deployed. It is perfectly okay if what we propose takes ten years to see widespread deployment. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On Thu, 15 Nov 2012, Ted Lemon wrote: On Nov 15, 2012, at 6:20 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: It's my opinion that we can't rely on 5.5 working. Hosts need to not support 5.5 and things should still work. Why do hosts need to not support 5.5? From RFC6724: Discussion: An IPv6 implementation is not required to remember which next-hops advertised which prefixes. The conceptual models of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191] have no such requirement. Hence, Rule 5.5 is only applicable to implementations that track this information. So since 5.5 is not a MUST (and most hosts today do not support 5.5 as far as I know), designing HOMENET based on 5.5 support on all hosts seems misdirected. ... or what am I missing? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
Mikael, It's my opinion that we can't rely on 5.5 working. Hosts need to not support 5.5 and things should still work. Why do hosts need to not support 5.5? From RFC6724: Discussion: An IPv6 implementation is not required to remember which next-hops advertised which prefixes. The conceptual models of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191] have no such requirement. Hence, Rule 5.5 is only applicable to implementations that track this information. So since 5.5 is not a MUST (and most hosts today do not support 5.5 as far as I know), designing HOMENET based on 5.5 support on all hosts seems misdirected. ... or what am I missing? how do you want it to work? the tools we have currently are: - ICMP redirect - ICMP type 1, code 5 - DHCP option for SAS/DAS policy - RFC6724 rule 5.5 - RFC4191 what is missing? cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On Thu, 15 Nov 2012, Ole Trøan wrote: how do you want it to work? the tools we have currently are: - ICMP redirect - ICMP type 1, code 5 - DHCP option for SAS/DAS policy - RFC6724 rule 5.5 - RFC4191 what is missing? In my mind, I was looking at a new mechanism that the ISP routers used to tell each other what prefix they were advertising and handing out. I couldn't find specifics on DHCP option for SAS/DAS policy, so I don't know what that means exactly. Could you give a pointer? If I read https://github.com/otroan/IETF-CPE-router/wiki my guess is that it is more for the homenet router when they get DHCPv6-PD, but I might be mistaken? But relying on RFC6724 rule 5.5 for all hosts seems unfeasable. I'd rather solve getting the correct traffic to the correct ISP router on the ISP router level, not in the hosts. So no ICMP redirects, just source based routing between the ISP routers. -- Mikael Abrahamssonemail: swm...@swm.pp.se___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
Mikael, how do you want it to work? the tools we have currently are: - ICMP redirect - ICMP type 1, code 5 - DHCP option for SAS/DAS policy - RFC6724 rule 5.5 - RFC4191 what is missing? In my mind, I was looking at a new mechanism that the ISP routers used to tell each other what prefix they were advertising and handing out. the kind of do with http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-03 but you can't a) expect the ISP routers to be able to discover each other (might not be on the same link), b) operated by the same entity. I couldn't find specifics on DHCP option for SAS/DAS policy, so I don't know what that means exactly. Could you give a pointer? If I read https://github.com/otroan/IETF-CPE-router/wiki my guess is that it is more for the homenet router when they get DHCPv6-PD, but I might be mistaken? https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt/ this is more for multi-homing to non-congruent networks. But relying on RFC6724 rule 5.5 for all hosts seems unfeasable. I'd rather solve getting the correct traffic to the correct ISP router on the ISP router level, not in the hosts. So no ICMP redirects, just source based routing between the ISP routers. we're not, the RFC6724 rule only applies when a host is connected to two routers with different upstream connectivity. inside the home, i.e the host is behind two internal home routers, SADR is used to get to the correct border. the only thing we're asking for here is that the hosts also do a simplified form for SADR when directly connected to multiple border routers. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On Thu, 15 Nov 2012, Ole Trøan wrote: In my mind, I was looking at a new mechanism that the ISP routers used to tell each other what prefix they were advertising and handing out. the kind of do with http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-03 but you can't a) expect the ISP routers to be able to discover each other (might not be on the same link), b) operated by the same entity. b) I never imagined, a) would be nice if that could be solved. I don't see any text in that draft regarding source based routing though. I couldn't find specifics on DHCP option for SAS/DAS policy, so I don't know what that means exactly. Could you give a pointer? If I read https://github.com/otroan/IETF-CPE-router/wiki my guess is that it is more for the homenet router when they get DHCPv6-PD, but I might be mistaken? https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt/ this is more for multi-homing to non-congruent networks. But relying on RFC6724 rule 5.5 for all hosts seems unfeasable. I'd rather solve getting the correct traffic to the correct ISP router on the ISP router level, not in the hosts. So no ICMP redirects, just source based routing between the ISP routers. we're not, the RFC6724 rule only applies when a host is connected to two routers with different upstream connectivity. inside the home, i.e the host is behind two internal home routers, SADR is used to get to the correct border. What happens if the host doesn't support 5.5? the only thing we're asking for here is that the hosts also do a simplified form for SADR when directly connected to multiple border routers. So, I still can't find anything about a mechanism for routers in homenet for network-wide discovery of where a certain src address packet should be sent when it's destined for the default route (to the Internet). Why can't OSPF be used (needs new functionality) so that all homenet routers learn a default-route per prefix, and thus have multiple default routes, and select which one to use depending on what the src address is of the packet? That would relieve the hosts of having to do anything at all (it is nice if they can do 5.5, but things wouldn't break without it). Basically multi-topology but instead of being one for IPv4 and one for IPv6, we now have one topology per ISP allocated prefix. Or am I missing things again? I would really like to avoid requiring functionality in the hosts as I see this as a big obstacle to get homenet implemented in real life. -- Mikael Abrahamssonemail: swm...@swm.pp.se___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
Mikael, In my mind, I was looking at a new mechanism that the ISP routers used to tell each other what prefix they were advertising and handing out. the kind of do with http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-03 but you can't a) expect the ISP routers to be able to discover each other (might not be on the same link), b) operated by the same entity. b) I never imagined, a) would be nice if that could be solved. I don't see any text in that draft regarding source based routing though. correct, we haven't described that anywhere I think. I couldn't find specifics on DHCP option for SAS/DAS policy, so I don't know what that means exactly. Could you give a pointer? If I read https://github.com/otroan/IETF-CPE-router/wiki my guess is that it is more for the homenet router when they get DHCPv6-PD, but I might be mistaken? https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt/ this is more for multi-homing to non-congruent networks. But relying on RFC6724 rule 5.5 for all hosts seems unfeasable. I'd rather solve getting the correct traffic to the correct ISP router on the ISP router level, not in the hosts. So no ICMP redirects, just source based routing between the ISP routers. we're not, the RFC6724 rule only applies when a host is connected to two routers with different upstream connectivity. inside the home, i.e the host is behind two internal home routers, SADR is used to get to the correct border. What happens if the host doesn't support 5.5? one of the other things in my list happens. ICMP type 1,code 5 ICMP redirect blackhole . . the only thing we're asking for here is that the hosts also do a simplified form for SADR when directly connected to multiple border routers. So, I still can't find anything about a mechanism for routers in homenet for network-wide discovery of where a certain src address packet should be sent when it's destined for the default route (to the Internet). Why can't OSPF be used (needs new functionality) so that all homenet routers learn a default-route per prefix, and thus have multiple default routes, and select which one to use depending on what the src address is of the packet? That would relieve the hosts of having to do anything at all (it is nice if they can do 5.5, but things wouldn't break without it). Basically multi-topology but instead of being one for IPv4 and one for IPv6, we now have one topology per ISP allocated prefix. Or am I missing things again? no, this is pretty much what we imagined, and what Markus has implemented and showed at the IETF. the hosts would still do better if they support rule 5.5 when directly connected to the exits. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On Thu, 15 Nov 2012, Ole Trøan wrote: Or am I missing things again? no, this is pretty much what we imagined, and what Markus has implemented and showed at the IETF. the hosts would still do better if they support rule 5.5 when directly connected to the exits. Absolutely, 5.5 is a plus and gives one less hop in the path, but at least the packet will be ultimately delivered to its final destination. So with the above pretty much what we have imagined, is there consensus that this is the way to go, or this is still being debated? -- Mikael Abrahamssonemail: swm...@swm.pp.se___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
Mikael, Given that we want multiprefix multihoming with multiple prefixes, SADR is pretty much the only solution. But consesus? Wouldn't dear getting anywhere close to that. :-) Cheers, Ole On 15 Nov 2012, at 16:15, Mikael Abrahamsson swm...@swm.pp.se wrote: On Thu, 15 Nov 2012, Ole Trøan wrote: Or am I missing things again? no, this is pretty much what we imagined, and what Markus has implemented and showed at the IETF. the hosts would still do better if they support rule 5.5 when directly connected to the exits. Absolutely, 5.5 is a plus and gives one less hop in the path, but at least the packet will be ultimately delivered to its final destination. So with the above pretty much what we have imagined, is there consensus that this is the way to go, or this is still being debated? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] prefix assignment on home networks
Am 15.11.2012 13:09, schrieb Brian E Carpenter: On 15/11/2012 10:19, Mattia Rossi wrote: On Thu, Nov 15, 2012 at 9:16 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 14/11/2012 22:44, james woodyatt wrote: On Nov 14, 2012, at 13:34 , Mikael Abrahamsson swm...@swm.pp.se wrote: I've always seen it to be solved via some kind of source based routing automatically discovered between the ISP routers. My point is that it isn't sufficient to handle this problem at just the routers. At a minimum, the *hosts* need to be told which default router to use with each source prefix. Of course. I suggested this when MIF started out, and it's a MIF issue still. The hosts do already select the correct router depending on the prefix. They're tied together. An RA contains a prefix and router address. That's what the host keeps in memory. Where is that specified? And what if the network is using DHCPv6 to provide such information? The strongest statement I can find in RFC 6724 about this is a MAY in section 7, which doesn't make this predictable. It's exactly that section. The MAY obviously leaves a lot of room there. About DHCPv6 I don't know as I haven't tried that. Good question. If it's two RA's one router becomes default, the other more specific. The two might be of equal standing and both offer a route to ::/0. Well, actually true.. So, yes you're right, source based routing in the host should become a MUST. The host/applications will also only use one prefix at a time, thus always send the packets down the correct path. I don't believe that is fully specified either. Each new socket might make a new choice. Different apps might use different addresses, the same app probably not. They would reuse the same socket options all the time I believe. Anyhow, this is just what I've observed so far. It's not how it probably should/could be. In my experience it was always the same prefix, the one that got registered first (if no preference was setup in the advertising router). If the host is connected via two or more interfaces (so we're in MIF area now), there will always be one preferred prefix, and interface, and the outgoing routing will work. Then why is MIF still arguing? Because this behaviour is not ideal. It's what I've observed, and probably the result of an unfinished implementation due to lack of specification. Somebody had to fix things somehow. If applications are able to chose a specific prefix (e.g. VPN) they usually implement some source routing on the host anyways, and send the packets to the router registered with that prefix. Sure, but we are worried here about zero-conf defaults. Yes. Source based routing a MUST. I agree. If you have an application listening for incoming connections, then it's important that the application is smart enough to use the address on which the incoming connection arrived as source address, and not the default one which might be on a different prefix to avoid asynchronous communication. As far as I know this is already common practice. Not good enough - it needs to be specified. I agree. That might be something to add to RFC 3484. Unless it's already in there, but I couldn't find it. So I don't really see a problem here, unless you want to do some fancy load sharing and play ping pong with source addresses. If there's only one interface which connects to a multihomed router, the principle is the same, but the multihomed router must be able to perform source address routing, and forward the packets down the right path. And this is something I'm not too sure about routers can currently do. Indeed. Again, this needs specifying, as does behaviour when there are multiple routers and one of them receives a packet that should exit via another one. https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat/ Ah, something new to read. Thanks, Mat ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
behind a 2nd router behind my general-purpose home network router (the one that gets a /64 from 6rd). Right now, I can't, AFAIK. Since I have all of these connections, it would be nice if I didn't have to physically move between them, but could have them connected together and just configure a few simple choices to make things work (the way *I* want them to work -- so I do expect some simple configuration). Getting my multihoming working is more of a nice to have right now, though, since I've got to keep IPv4 working right, and I don't see anything being done to solve IPv4 multihoming. I thinks that's something that I won't bother trying to change. The cascaded router scenario (in the tethered single-stack wireless network and in my general purpose home network) works today with IPv4. But not with IPv6. That's a problem. The /64 is very real in both of those cases, and breath-holding or crying about it just doesn't seem to be a very effective approach. That's my consumer wish list. Thanks for listening. Maybe I'll put this in my letter to Santa. Barbara -Original Message- From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf Of Randy Turner Sent: Wednesday, November 14, 2012 1:58 PM To: homenet@ietf.org Subject: Re: [homenet] prefix assignment on home networks I'm not against one or more /64 bit prefixes for a home net, if everyone else (including the ISPs) think that home networks should be able to scale up to 18,446,744,073,709,551,615 hosts, I'm completely on board. It's not my resource, so I'll take all they give me. :) It would be nice to have an ATT, Verizon, or some other major provider chime in to say they're on board with the assumptions we're making. Maybe they already have, I've been away from the list for awhile, or maybe they've indicated this allocation strategy in some other forum. I'm old school and I'm not used to having publicly routable address space to burn. Randy On Nov 14, 2012, at 10:40 AM, Andrew McGregor wrote: I have a /48 at home, on a retail ISP, right now. I know, one data point does not a trend make, but it is a proof by example that some ISP is doing that. Andrew On 15/11/2012, at 6:27 AM, Randy Turner rtur...@amalfisystems.com wrote: Have their been any ISPs that have come forward to discuss their consumer IPv6 allocation plans? I don't think we should wrap ourselves around a model that says, yeah, we need multiple /64s for consumers because that's the way a particular protocol works (SLAAC). Maybe we need another method. One /64 for a home network seems like overkill regarding address space utilization -- A /32 would be overkill. I know some folks think we have more address space than we'll ever use, but gee Randy On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote: On Nov 14, 2012, at 3:31 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 14/11/2012 02:34, Randy Turner wrote: I was thinking that, in an effort to reduce scope to something we can deal with for now, that a /64 would be big enough It simply isn't, because it doesn't allow subnetting in the home/car/small office or whatever. I don't see the point in working on the /64 case-if that's all we're trying to accomplish, we've already accomplished it. The interesting work Homenet is doing is in fact trying to solve the prefix distribution and automatic setup problem. It's true that this is a hard problem. It's also true that if we don't specify a solution, people will attempt to solve it in their own ways. And if they do that, we will wind up in the situation that Jim found himself in with his broken box with its own built-in DHCP server. BTW, a little more on that topic: the reason that two DHCP servers on the same wire broke Jim's network in a flaky way is that IPv4 doesn't handle the multi-homing case. IPv6 deliberately places the multi-homing case in- scope. This creates a bit of a problem for legacy apps that do not support multi-homing, but it also creates the winning situation that if one device is advertising a provisioning domain that doesn't work, applications that do correctly handle multi-homing will simply use a different provisioning domain. ___ 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 ___ 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] prefix assignment on home networks
NAT464 to get to IPv4 endpoints behind a single-stack IPv6 connection). I'd also like to do IPv6 to IPv6 endpoints from behind a 2nd router behind my general-purpose home network router (the one that gets a /64 from 6rd). Right now, I can't, AFAIK. Since I have all of these connections, it would be nice if I didn't have to physically move between them, but could have them connected together and just configure a few simple choices to make things work (the way *I* want them to work -- so I do expect some simple configuration). Getting my multihoming working is more of a nice to have right now, though, since I've got to keep IPv4 working right, and I don't see anything being done to solve IPv4 multihoming. I thinks that's something that I won't bother trying to change. The cascaded router scenario (in the tethered single-stack wireless network and in my general purpose home network) works today with IPv4. But not with IPv6. That's a problem. The /64 is very real in both of those cases, and breath-holding or crying about it just doesn't seem to be a very effective approach. That's my consumer wish list. Thanks for listening. Maybe I'll put this in my letter to Santa. Barbara -Original Message- From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf Of Randy Turner Sent: Wednesday, November 14, 2012 1:58 PM To: homenet@ietf.org Subject: Re: [homenet] prefix assignment on home networks I'm not against one or more /64 bit prefixes for a home net, if everyone else (including the ISPs) think that home networks should be able to scale up to 18,446,744,073,709,551,615 hosts, I'm completely on board. It's not my resource, so I'll take all they give me. :) It would be nice to have an ATT, Verizon, or some other major provider chime in to say they're on board with the assumptions we're making. Maybe they already have, I've been away from the list for awhile, or maybe they've indicated this allocation strategy in some other forum. I'm old school and I'm not used to having publicly routable address space to burn. Randy On Nov 14, 2012, at 10:40 AM, Andrew McGregor wrote: I have a /48 at home, on a retail ISP, right now. I know, one data point does not a trend make, but it is a proof by example that some ISP is doing that. Andrew On 15/11/2012, at 6:27 AM, Randy Turner rtur...@amalfisystems.com wrote: Have their been any ISPs that have come forward to discuss their consumer IPv6 allocation plans? I don't think we should wrap ourselves around a model that says, yeah, we need multiple /64s for consumers because that's the way a particular protocol works (SLAAC). Maybe we need another method. One /64 for a home network seems like overkill regarding address space utilization -- A /32 would be overkill. I know some folks think we have more address space than we'll ever use, but gee Randy On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote: On Nov 14, 2012, at 3:31 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 14/11/2012 02:34, Randy Turner wrote: I was thinking that, in an effort to reduce scope to something we can deal with for now, that a /64 would be big enough It simply isn't, because it doesn't allow subnetting in the home/car/small office or whatever. I don't see the point in working on the /64 case-if that's all we're trying to accomplish, we've already accomplished it. The interesting work Homenet is doing is in fact trying to solve the prefix distribution and automatic setup problem. It's true that this is a hard problem. It's also true that if we don't specify a solution, people will attempt to solve it in their own ways. And if they do that, we will wind up in the situation that Jim found himself in with his broken box with its own built-in DHCP server. BTW, a little more on that topic: the reason that two DHCP servers on the same wire broke Jim's network in a flaky way is that IPv4 doesn't handle the multi-homing case. IPv6 deliberately places the multi-homing case in- scope. This creates a bit of a problem for legacy apps that do not support multi-homing, but it also creates the winning situation that if one device is advertising a provisioning domain that doesn't work, applications that do correctly handle multi-homing will simply use a different provisioning domain. ___ 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 ___ 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman
Re: [homenet] prefix assignment on home networks
On Nov 15, 2012, at 12:27 PM, STARK, BARBARA H bs7...@att.com wrote: The cascaded router scenario (in the tethered single-stack wireless network and in my general purpose home network) works today with IPv4. But not with IPv6. That's a problem. The /64 is very real in both of those cases, and breath-holding or crying about it just doesn't seem to be a very effective approach. Thanks for the long expression of your use case—I think it's a useful example. I do want to take exception to one thing here, though: cascaded routers do not work with IPv4. They work with IPv4+NAT, or with IPv4+bridge. And work is relative, as your use case story shows. Chances are that part of the reason you had to go to a multi-homed connection was that your router configuration was suffering from bufferbloat, and so despite you having a decent connection to your ISP, you were experiencing congestion. This is, unfortunately, very typical of home routers nowadays. Adding a second entire network for your own private use worked, but it was probably overkill. If you are feeling adventurous, you might want to try setting up a CeroWRT network with properly tuned buffers and see if it changes things for you. I can't promise that it does—I'm just a happy user of CeroWRT, not an expert on bufferbloat. But the network behavior you are describing sounds a lot like what I was trying to cure when I installed CeroWRT. What does this have to do with the homenet discussion? We should be proposing a solution that doesn't perpetuate the architecture that leads to bufferbloat. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
Chances are that part of the reason you had to go to a multi-homed connection was that your router configuration was suffering from bufferbloat, and so despite you having a decent connection to your ISP, you were experiencing congestion. This is, unfortunately, very typical of home routers nowadays. No, my connection to my first ISP is 1.5Mbps downstream. The 2nd connection is 30Mbps downstream. A single Netflix stream had no difficulty taking up the entire 1.5Mbps. Unfortunately, the technology used to offer the 1.5Mbps service could only be upgraded to a maximum of 3Mbps. I figured Netflix could probably overrun that too, so I went with the 2nd connection. I could have just switched everything to the 2nd connection (my routers haven't had any difficulty with doing everything asked of them on the 30 Mbps connection -- Netflix users are very happy and the shrieks from the MMORPG addict mourning death due to lousy Internet connectivity have stopped), but I like the redundancy of having 2, and the 1.5 Mbps service is very inexpensive. Adding a second entire network for your own private use worked, but it was probably overkill. Not overkill. Just redundant. But I and my family need our Internet. We cannot live without it. Redundancy is good when it isn't expensive. If you are feeling adventurous, you might want to try setting up a CeroWRT network with properly tuned buffers and see if it changes things for you. I can't promise that it does-I'm just a happy user of CeroWRT, not an expert on bufferbloat. But the network behavior you are describing sounds a lot like what I was trying to cure when I installed CeroWRT. Hmm. I'm busy with other adventures right now, and not feeling the need. I'll keep it in mind, though. What does this have to do with the homenet discussion? We should be proposing a solution that doesn't perpetuate the architecture that leads to bufferbloat. /64s are very real, and the need to accommodate them appears to be relatively near-term. Multi-homing is real. Improved multi-homing experience is desirable, but not an immediate need. A diagnosis of bufferbloat sounds difficult to cure (requiring adventures and acronyms), so I think I'll stick with my state of denial regarding that. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
But when (single stack) IPv6 gets offered on that tether, that router will only have a single /128 address. Hmm. http://tools.ietf.org/html/draft-byrne-v6ops-64share-03 is one proposal. Which, I suspect, is how the router would get that single /128 address. That works nice for the 3GPP tethering device to know it has a /64 that it can offer for SLAAC use to tethered (non-3GPP) devices to self-assign a /128. It's not so useful for my tethered (non-3GPP) off-the-shelf home networking router connected out its WAN port to the tethering device through an Ethernet/Wi-Fi bridge, to provide addresses to the home network on its LAN. Not all of the devices on my home network do Wi-Fi. And even if they did, homing them all to point to the tethering device (many of which only support 3 or so tethered devices) would require effort. It's much easier for me to configure a single Ethernet/Wi-Fi bridge to point to the tethering device, and plug that into the WAN port of a regular home router. I know how to do this (in the IPv4 world). I could even describe to my mother-in-law how to do this. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On 11/15/12 10:41 AM, STARK, BARBARA H wrote: But when (single stack) IPv6 gets offered on that tether, that router will only have a single /128 address. Hmm. http://tools.ietf.org/html/draft-byrne-v6ops-64share-03 is one proposal. Which, I suspect, is how the router would get that single /128 address. That works nice for the 3GPP tethering device to know it has a /64 that it can offer for SLAAC use to tethered (non-3GPP) devices to self-assign a /128. It's not so useful for my tethered (non-3GPP) off-the-shelf home networking router connected out its WAN port to the tethering device through an Ethernet/Wi-Fi bridge, to provide addresses to the home network on its LAN. There are somewhat limited options in my understanding with 3gpp release 7 networks, this sounds like a relatively good idea given the limitations but it's use generally seems like kind of a bad idea. That said I'm in favor of bad options over no options, and I think it's heartening to see operators try and make this work. Not all of the devices on my home network do Wi-Fi. really only one of them has to in the case of a bridge, And even if they did, homing them all to point to the tethering device (many of which only support 3 or so tethered devices) would require effort. The limit on the supported number of tethered devices is somewhat arbitrary, a usb dongle in business style cpe doesn't have the same limitations that my mifi does It's much easier for me to configure a single Ethernet/Wi-Fi bridge to point to the tethering device, and plug that into the WAN port of a regular home router. I know how to do this (in the IPv4 world). I could even describe to my mother-in-law how to do this. I would agree that if it's not easy it's likely not going to workable general case. mobile phones that provide the bulk of the tethering capability already bind to the homenet (as clients/hosts) so they've already built the association necessary to offer service. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
There are somewhat limited options in my understanding with 3gpp release 7 networks, this sounds like a relatively good idea given the limitations but it's use generally seems like kind of a bad idea. That said I'm in favor of bad options over no options, and I think it's heartening to see operators try and make this work. Um, I really tried to indicate that my views were mine and were intended to reflect my thoughts as a consumer. Not an operator. So please don't feel quite so heartened. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On Nov 15, 2012, at 04:26 , Ted Lemon mel...@fugue.com wrote: On Nov 14, 2012, at 10:41 PM, james woodyatt j...@apple.com wrote: However notionally easy this problem is to address, I imagine that practical matters, at some point, must rise to the top of the pile of points to consider. Those hosts are broken. They can't work in a multi-homed environment. Those hosts are not broken. They work fine in single-homed edge networks, which are ubiquitous. The deployment of multiple heterogenous default routers with hosts that expect networks to be single-homed is what breaks the network. Also, rule 5.5 of RFC 6724 is inadequate. Hosts that implement it should work better than those that don't because new flows created after the primary default router becomes unreachable should automatically go to the next available default router, but existing flows will still be broken in the absence of the kind of coordination I described previously. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On Nov 15, 2012, at 4:04 PM, james woodyatt j...@apple.com wrote: Those hosts are not broken. They work fine in single-homed edge networks, which are ubiquitous. The deployment of multiple heterogenous default routers with hosts that expect networks to be single-homed is what breaks the network. It breaks the network because hosts in this environment cannot be counted on to do the obviously right thing, but instead are encouraged by the standard to behave in ways that can be counted on to be wrong almost all the time. It's true that they are not broken with respect to the standard, but what the standard encourages them to do is the very essence of what it means to be broken. We should fix it, not wring our hands and point out reasons why it's not our fault that the standard and the hosts that follow it are broken. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On 13/11/2012 17:47, james woodyatt wrote: On Nov 13, 2012, at 10:33 , Randy Turner rtur...@amalfisystems.com wrote: I've been away from the list for awhile, and am trying to catch up -- is there a reference or quick explanation as to why a /64 assigned to a home network is considered to be potentially constrained somehow ? Once upon a time [RFC 3177], we believed that creating a numbering plan for subscriber networks was intolerably difficult and expensive, so we thought it would be a very good idea to make sure every new subscriber of any size would a /48 delegation, which we all thought was big enough for all but the most titanic of organizations. The idea was you'd get enough space up front that you could take your numbering plan with you if you ever moved from one provider to another. Space was thought to be too cheap to meter, and the benefit of number plan stability across providers was thought to be beneficial. Since then, we have discovered two things: A) service providers guard with astonishing ferocity every last number they get from their registries even when they are too cheap to meter, and B) the problem of number plan scaling is one that only people without any money have any interest in seeing solved. Hence, we have a new recommendation from IAB [RFC 6177], which capitulates on the one-size-fits-all recommendation. It also says this in section 2: However, this precludes the expectation that even home sites will grow to support multiple subnets going forward. Hence, it is strongly intended that even home sites be given multiple subnets worth of space, by default. Hence, this document still recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either. For my part, I have a hard time foreseeing how the expectation that residential sites will always have more space to assign than a single /64 subnet is even remotely reasonable. Far too many service providers are casting into operational concrete topologies that assign only one subnet to each billable subscriber gateway. I don't hold out much hope that much of a market will ever exist for residential networks with multiple subnets per subscriber. I also don't hold out much hope for the kind of coordination between service providers that will permit multihomed residential sites to work well. That's why it looks to me like HOMENET will eventually converge on specifying single /64 links behind a single residential gateway. I think Homenet should not make the assumption that the different networks are from a larger block like /5x but rather a collection /64's. Think about the dual ISP connection case, the ISPa/xx allocated blocks is quite likely to be disjoint from the ISPb/yy allocated blocks, and xx != yy is quite possible. Olafur ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On Nov 14, 2012, at 3:31 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 14/11/2012 02:34, Randy Turner wrote: I was thinking that, in an effort to reduce scope to something we can deal with for now, that a /64 would be big enough It simply isn't, because it doesn't allow subnetting in the home/car/small office or whatever. I don't see the point in working on the /64 case—if that's all we're trying to accomplish, we've already accomplished it. The interesting work Homenet is doing is in fact trying to solve the prefix distribution and automatic setup problem. It's true that this is a hard problem. It's also true that if we don't specify a solution, people will attempt to solve it in their own ways. And if they do that, we will wind up in the situation that Jim found himself in with his broken box with its own built-in DHCP server. BTW, a little more on that topic: the reason that two DHCP servers on the same wire broke Jim's network in a flaky way is that IPv4 doesn't handle the multi-homing case. IPv6 deliberately places the multi-homing case in-scope. This creates a bit of a problem for legacy apps that do not support multi-homing, but it also creates the winning situation that if one device is advertising a provisioning domain that doesn't work, applications that do correctly handle multi-homing will simply use a different provisioning domain. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
Op 14 nov. 2012, om 16:07 heeft Ted Lemon het volgende geschreven: On Nov 14, 2012, at 3:31 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 14/11/2012 02:34, Randy Turner wrote: I was thinking that, in an effort to reduce scope to something we can deal with for now, that a /64 would be big enough It simply isn't, because it doesn't allow subnetting in the home/car/small office or whatever. I don't see the point in working on the /64 case—if that's all we're trying to accomplish, we've already accomplished it. The interesting work Homenet is doing is in fact trying to solve the prefix distribution and automatic setup problem. It's true that this is a hard problem. It's also true that if we don't specify a solution, people will attempt to solve it in their own ways. And if they do that, we will wind up in the situation that Jim found himself in with his broken box with its own built-in DHCP server. BTW, a little more on that topic: the reason that two DHCP servers on the same wire broke Jim's network in a flaky way is that IPv4 doesn't handle the multi-homing case. IPv6 deliberately places the multi-homing case in-scope. This creates a bit of a problem for legacy apps that do not support multi-homing, but it also creates the winning situation that if one device is advertising a provisioning domain that doesn't work, applications that do correctly handle multi-homing will simply use a different provisioning domain. Yes, this is the use case I'm interested in. I don't think it is to hard to get there, as long as we don't try to hide the more complex network topology and DHCP facilities from hosts. We must be backward compatible, but should not block enhancements. Teco ___ 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] prefix assignment on home networks
On 11/14/2012 07:07 AM, Ted Lemon wrote: BTW, a little more on that topic: the reason that two DHCP servers on the same wire broke Jim's network in a flaky way is that IPv4 doesn't handle the multi-homing case. IPv6 deliberately places the multi-homing case in-scope. This creates a bit of a problem for legacy apps that do not support multi-homing, but it also creates the winning situation that if one device is advertising a provisioning domain that doesn't work, applications that do correctly handle multi-homing will simply use a different provisioning domain. I'm guessing the main problem wasn't multihoming per se: they were both probably giving out 192.168 addresses, which would be a problem in v6 were it to happen too. And of course even if they didn't collide, it could still be a problem if the rogue dhc were pointing the host to a router that doesn't have the route the dhc says it does. But the real question I have is: what constitutes a legacy app? How do I know if I've written one or not? Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
Op 14 nov. 2012, om 16:58 heeft Michael Thomas het volgende geschreven: On 11/14/2012 07:07 AM, Ted Lemon wrote: BTW, a little more on that topic: the reason that two DHCP servers on the same wire broke Jim's network in a flaky way is that IPv4 doesn't handle the multi-homing case. IPv6 deliberately places the multi-homing case in-scope. This creates a bit of a problem for legacy apps that do not support multi-homing, but it also creates the winning situation that if one device is advertising a provisioning domain that doesn't work, applications that do correctly handle multi-homing will simply use a different provisioning domain. I'm guessing the main problem wasn't multihoming per se: they were both probably giving out 192.168 addresses, which would be a problem in v6 were it to happen too. And of course even if they didn't collide, it could still be a problem if the rogue dhc were pointing the host to a router that doesn't have the route the dhc says it does. I say the routers do run a protocol that support multihoming. The current direction is routing based on source and destination address (or destination and source, order is less important here). Hosts may send packets to whatever router. It is important that correct interface is selected. This is a MIF topic. But the real question I have is: what constitutes a legacy app? How do I know if I've written one or not? More important: how to write non-legacy apps that do provide the more enhanced robustness. Or upgrade the stack, as mptcp. 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] prefix assignment on home networks
I'm not against one or more /64 bit prefixes for a home net, if everyone else (including the ISPs) think that home networks should be able to scale up to 18,446,744,073,709,551,615 hosts, I'm completely on board. It's not my resource, so I'll take all they give me. :) It would be nice to have an ATT, Verizon, or some other major provider chime in to say they're on board with the assumptions we're making. Maybe they already have, I've been away from the list for awhile, or maybe they've indicated this allocation strategy in some other forum. I'm old school and I'm not used to having publicly routable address space to burn. Randy On Nov 14, 2012, at 10:40 AM, Andrew McGregor wrote: I have a /48 at home, on a retail ISP, right now. I know, one data point does not a trend make, but it is a proof by example that some ISP is doing that. Andrew On 15/11/2012, at 6:27 AM, Randy Turner rtur...@amalfisystems.com wrote: Have their been any ISPs that have come forward to discuss their consumer IPv6 allocation plans? I don't think we should wrap ourselves around a model that says, yeah, we need multiple /64s for consumers because that's the way a particular protocol works (SLAAC). Maybe we need another method. One /64 for a home network seems like overkill regarding address space utilization -- A /32 would be overkill. I know some folks think we have more address space than we'll ever use, but gee…. Randy On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote: On Nov 14, 2012, at 3:31 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 14/11/2012 02:34, Randy Turner wrote: I was thinking that, in an effort to reduce scope to something we can deal with for now, that a /64 would be big enough It simply isn't, because it doesn't allow subnetting in the home/car/small office or whatever. I don't see the point in working on the /64 case—if that's all we're trying to accomplish, we've already accomplished it. The interesting work Homenet is doing is in fact trying to solve the prefix distribution and automatic setup problem. It's true that this is a hard problem. It's also true that if we don't specify a solution, people will attempt to solve it in their own ways. And if they do that, we will wind up in the situation that Jim found himself in with his broken box with its own built-in DHCP server. BTW, a little more on that topic: the reason that two DHCP servers on the same wire broke Jim's network in a flaky way is that IPv4 doesn't handle the multi-homing case. IPv6 deliberately places the multi-homing case in-scope. This creates a bit of a problem for legacy apps that do not support multi-homing, but it also creates the winning situation that if one device is advertising a provisioning domain that doesn't work, applications that do correctly handle multi-homing will simply use a different provisioning domain. ___ 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On Nov 13, 2012, at 21:30 , joel jaeggli joe...@bogus.com wrote: On 11/13/12 9:20 PM, Mikael Abrahamsson wrote: Why do you believe we need coordination between service providers to permit multihomed services to work well? I thought the whole idea was to handle multiple upstream prefixes and make sure everything is routed to the correct ISP? If coordination is required, it's not going to work. Let's put on our thinking caps. Say I have a HOMENET with two provider-provisioned border gateways, each from different providers. Let's call them ALFA Broadband and BRAVO Networks. Say that ALFA delegates 2001:db8:::/64 to me and BRAVO delegates 2001:db8:::/64 to me (yes, they could delegate shorter prefixes, but let's say I have only one link to number, so the prefixes above are the ones that each gateway will be advertising in Router Advertisement messages on my HOMENET link). When they're both up and running, each router is a default gateways on my link. Each host gets two prefixes on the link, i.e. 2001:db8:::/64 and 2001:db8:::/64 and a default router list comprising both the gateways for ALFA and BRAVO. Given how the hosts in the field today behave, only one of the routers will be forwarding outbound packets. Which is fine. Let's say my gateway from ALFA is the default router all my hosts always pick, i.e. it's at the front of the default router list. Now let's say a host on my network chooses to connect to a remote destination where source address selection rules say that it should pick an address from the BRAVO prefix delegation. The SYN packet with source address 2001:db8:::X goes to the ALFA router. What does it do with that? - Does it forward the packet? If so, then the return path will be asymmetric, i.e. it will come back through my BRAVO gateway. Asymmetric paths are the reason 6to4 anycast is broken. I thought we learned our lesson about that. Maybe not all of us did, but I bet we soon will if we keep going this road. - Does it recognize the 2001:db8:::/64 prefix and redirect to the BRAVO router? If so, then how does it know to do that? Coordination, because routers don't process Router Advertisements, so the ALFA gateway won't have reason to know about the BRAVO prefix unless it makes an exception to the standard rules. I'm not optimistic that the players involved will have any incentive to adopt protocols that enable that happen.This all sounds very squirrelly to me, and the incentives to do it seem completely missing in action. (By the way, how do you redirect a whole prefix? You don't. How do you cancel a redirection? You don't. How do we fix this? By getting 6MAN to revise Router Advertisements and rolling out new host implementations everywhere. Good luck with that. Oh but wait: maybe, the ALFA router doesn't redirect, but it forwards instead. Path asymmetry again— just not as badly asymmetric as it would otherwise be, i.e. asymmetry is confined to the local link.) Maybe I'm missing something, but I think this is really an intractable problem, given what I know about it. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On Nov 14, 2012, at 17:22 , Michael Richardson mcr+i...@sandelman.ca wrote: james My point is that it isn't sufficient to handle this problem james at just the routers. At a minimum, the *hosts* need to be james told which default router to use with each source prefix. james Right now the only mechanism that comes close to doing that james is ICMPv6 Redirect, which isn't suitable for addressing this james problem. the edge routers can fix things for the hosts. If they coordinate. Section 3.2.4 Multihoming of I-D.ietf-homenet-arch-06 goes into some detail about the challenges in the scenario under discussion in this thread, and it mentions two proposals by name: I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat I-D.baker-fun-multi-router Neither of which sufficiently answers my open questions about how multiple provider-provisioned subscriber gateways will coordinate forwarding of packets to the correct egress for their source prefix. Please don't misunderstand: I can imagine a routing protocol that could do what I-D.baker-fun-multi-router describes, more or less-- it would display the local path asymmetry I described previously, but that might not be a deal-killer. What I can't imagine is that operators of provider-provisioned subscriber gateway equipment will have any incentive to deploy such a routing protocol, and I can imagine several ruthless and selfish reasons for them to resist. For starters, imagine this scenario: I'm an unhappy customer of ALFA Broadband, which is the largest incumbent carrier in my region, and I want to add the scrappy local underdog bargain provider, BRAVO Networks, as an egress to my existing HOMENET installation, so I can be multi-homed while I renumber and transition from one service provider to another. When I sign up with BRAVO, they have to ask me: is this a new HOMENET, or do you have an existing HOMENET routing domain we need to join. If I tell BRAVO it's a new HOMENET, then I don't get be to be multihomed with ALFA because their equipment won't forward packets with ALFA's source address either to ALFA's router or to the global Internet. Sadness. Must tell them about the existing HOMENET installation then. If I tell BRAVO it's an existing HOMENET, then I can only be multihomed if I can also get ALFA's router to admit BRAVO's new router to the routing domain it serves, but ALFA provisioned the thing and configured it for me. It's a crude black box as far as I'm concerned, and that's just how both they and I like it. So, to complete this migration, I now have to call up ALFA and say to them, Hi, I just signed up with your competitor, and I'd like for the router you installed for me, with whatever firmware it's running, to cooperate with their new router, running who knows what, in the HOMENET routing domain you set up for me years ago when I first signed up. Would you please reconfigure? Kthxbai! Any guesses what their response is likely to be? I'm honestly not sure how we expect this to work. It seems, either A) I have to be a highly technical mediator between ALFA Broadband and BRAVO Networks for the coordination of any HOMENET routing domain for which they're both going to provide access service, or B) they have to communicate directly with one another. Neither alternative seems very practical to me. this has been discussed on this list extensively. Without apparent resolution or the production of a draft as far as I can see. Hence my ongoing skepticism about this usage scenario. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On Nov 14, 2012, at 4:44 PM, james woodyatt j...@apple.com wrote: My point is that it isn't sufficient to handle this problem at just the routers. At a minimum, the *hosts* need to be told which default router to use with each source prefix. Right now the only mechanism that comes close to doing that is ICMPv6 Redirect, which isn't suitable for addressing this problem. This is at least notionally a very easy thing to do, since the source address they are using is in a prefix that they configured on the basis of a router advertisement. When would it make sense to send a packet with that source address to any router other than the one that advertised that prefix? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On 13/11/12 18:33, Randy Turner wrote: Hi All, I've been away from the list for awhile, and am trying to catch up -- is there a reference or quick explanation as to why a /64 assigned to a home network is considered to be potentially constrained somehow ? Because no IPv6 network can be smaller than /64 and have stateless autoconfiguration work. To have routed subnets in the homenet requires one /64 prefix per subnet, and a /64 prefix cannot be subnetted - it is already the smallest legal subnet. Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
I was thinking that, in an effort to reduce scope to something we can deal with for now, that a /64 would be big enough - and if this prefix is globally available on the internet, I think it's much more than the ISPs can get their heads around, at least for now. I understand the limitations of stateless autoconfig and other constraints, but I would start with something like a /64, but with a capability that allows multiple /64 prefixes (or other method for SLAAC) to be added later without a forklift upgrade or re-thinking of what we do first. Each home site could subnet this space, so we could include any new work on MDNSEXT or other name resolution that is decentralized but can cross subnets. I don't think we would be short-changing potential uses for home net by taking IPv6 baby steps for now….given that the ISPs and consumer home networks are not even as advanced as the multi-service IPv4 home network business models we were trying to sell to LECs/CLECS/ISPs when I was at 2Wire back in 2000. I (for one) would be thrilled if I could get an IPv6 /64 that is globally visible (not NAT'd) from my ISP. It's so much more than I have today. Randy On Nov 13, 2012, at 2:47 PM, james woodyatt j...@apple.com wrote: On Nov 13, 2012, at 10:33 , Randy Turner rtur...@amalfisystems.com wrote: I've been away from the list for awhile, and am trying to catch up -- is there a reference or quick explanation as to why a /64 assigned to a home network is considered to be potentially constrained somehow ? Once upon a time [RFC 3177], we believed that creating a numbering plan for subscriber networks was intolerably difficult and expensive, so we thought it would be a very good idea to make sure every new subscriber of any size would a /48 delegation, which we all thought was big enough for all but the most titanic of organizations. The idea was you'd get enough space up front that you could take your numbering plan with you if you ever moved from one provider to another. Space was thought to be too cheap to meter, and the benefit of number plan stability across providers was thought to be beneficial. Since then, we have discovered two things: A) service providers guard with astonishing ferocity every last number they get from their registries even when they are too cheap to meter, and B) the problem of number plan scaling is one that only people without any money have any interest in seeing solved. Hence, we have a new recommendation from IAB [RFC 6177], which capitulates on the one-size-fits-all recommendation. It also says this in section 2: However, this precludes the expectation that even home sites will grow to support multiple subnets going forward. Hence, it is strongly intended that even home sites be given multiple subnets worth of space, by default. Hence, this document still recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either. For my part, I have a hard time foreseeing how the expectation that residential sites will always have more space to assign than a single /64 subnet is even remotely reasonable. Far too many service providers are casting into operational concrete topologies that assign only one subnet to each billable subscriber gateway. I don't hold out much hope that much of a market will ever exist for residential networks with multiple subnets per subscriber. I also don't hold out much hope for the kind of coordination between service providers that will permit multihomed residential sites to work well. That's why it looks to me like HOMENET will eventually converge on specifying single /64 links behind a single residential gateway. -- 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] prefix assignment on home networks
On Tue, 13 Nov 2012, james woodyatt wrote: For my part, I have a hard time foreseeing how the expectation that residential sites will always have more space to assign than a single /64 subnet is even remotely reasonable. Far too many service providers are casting into operational concrete topologies that assign only one subnet to each billable subscriber gateway. Then those need to re-think their decisions. I don't hold out much hope that much of a market will ever exist for residential networks with multiple subnets per subscriber. I also don't hold out much hope for the kind of coordination between service providers that will permit multihomed residential sites to work well. Why do you believe we need coordination between service providers to permit multihomed services to work well? I thought the whole idea was to handle multiple upstream prefixes and make sure everything is routed to the correct ISP? That's why it looks to me like HOMENET will eventually converge on specifying single /64 links behind a single residential gateway. I hope not. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On 11/13/12 9:20 PM, Mikael Abrahamsson wrote: Why do you believe we need coordination between service providers to permit multihomed services to work well? I thought the whole idea was to handle multiple upstream prefixes and make sure everything is routed to the correct ISP? If coordination is required, it's not going to work. That's why it looks to me like HOMENET will eventually converge on specifying single /64 links behind a single residential gateway. I hope not. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
