Re: [homenet] When things go wrong on your homenet
On 13/11/2012 21:05, Michael Thomas wrote: On 11/13/2012 09:22 AM, Mark Townsley wrote: Each and every part of the router must do everything it can to work without bugging the user. it's enough work to bother them for the *really* important stuff like do I let this device on the network?, do I allow connectivity with my neighbor, etc. That and motherhood and apple pies. But then your home network melts down. Then what? I'll say again: we have no experience at all with mass deployment of complex zero-touch networks. In fact, we have no experience at all with mass deployment of anything other than flat networks with clients only. As Jim Getty's points out, we do have some experience with accidentally complex networks with poor to non-existent means to whip them back into submission and it's not pretty. Right. And we're creating a new profession here: Home Network Guru. I think that's inevitable, and there needs to be some way of telling the user Call your guru. (It's surprising what Google finds today when you type in homenet error.) Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Robustness in Homenet. (triggered by the DHCP-PD discussion).
Op 13 nov. 2012, om 21:19 heeft Simon Kelley het volgende geschreven: On 13/11/12 19:04, Jim Gettys wrote: So the recursive DHCP-PD scheme strikes me as something possibly very fragile. I really, really don't want to repeat the experience I had with having extra DHCP servers, and I would guess few ISP's do either. It seems to me much more robust to flood the key configuration information (prefixes, DNS, NTP, and the like) via a protocol that is really designed for the job (whether specifically for configuration, ie. ahcp http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/, or via the hacks on routing protocols like Ari has done with OSPF). Given that hosts are going to want to talk RA or DHCPv6, at least initially, one option down this route has the flood include the unicast address of a single, centralised DHCPv6 server, and routers run DHCP-relay agents which forward to that address. That gives you DHCPv6 functionality without recursive-PD complications. It also eliminates the problems of distributing the available prefixes as they traverse PD chains. Right. The one-and-only DHCP server knows about all the prefixes delegated from the ISP and the relays know which particular prefix has been given to the local router by the routing protocol or AHCP. I don't like a single DHCP server for multi-homed sites. This introduces unneeded complexity, it needs merging of information from multiple sources. This is completely incompatible with what MIF is doing (multiple provisioning domains). It also introduces an unneeded single point of failure. Multi-homing could be used for redundancy. Let's use a DHCP server for each ISP. In cases where a single CPE router connects to multiple ISPs, it can take two approaches: running multiple DHCP server instances, one for each ISP. Or perform the problematic integration. BRDP takes the per provisioning domain approach, where each provisioning domain is presented with a border router address (generated form provided prefix), with prefix length. Problem solved :-). Teco Simon. ___ 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] Robustness in Homenet. (triggered by the DHCP-PD discussion).
On 14/11/12 12:08, Teco Boot wrote: The one-and-only DHCP server knows about all the prefixes delegated from the ISP and the relays know which particular prefix has been given to the local router by the routing protocol or AHCP. I don't like a single DHCP server for multi-homed sites. This introduces unneeded complexity, it needs merging of information from multiple sources. This is completely incompatible with what MIF is doing (multiple provisioning domains). It also introduces an unneeded single point of failure. Multi-homing could be used for redundancy. Let's use a DHCP server for each ISP. In cases where a single CPE router connects to multiple ISPs, it can take two approaches: running multiple DHCP server instances, one for each ISP. Or perform the problematic integration. BRDP takes the per provisioning domain approach, where each provisioning domain is presented with a border router address (generated form provided prefix), with prefix length. Problem solved :-). OK. This raises some questions about DHCPv6 to which I don't know the answers. I hope Ted or someone else who was involved in the standard can answer. Simplest case first. Client and server on same link (in the RFC3315 definition of link) the server has an interface on the link which has multiple addresses with different prefixes, and it is configured to assign addresses on each of those prefixes. The client is unconfigured except for a link-local address. How does the client create a SOLICIT message which causes the server to reply with an ADVERTISE which offers the client an address with each of the prefixes ? The client doesn't know how many prefixes are available. Next case. The same as above but the SOLICIT transits via a relay. The relay can only insert one link address in the encapsulation, does the server have to know which prefixes share links so that it can determine which other prefixes are on the same link and reduce the problem to the case above? Next case. This speaks to Teco's suggestion. The same link with multiple prefixes, directly connected to servers, but now each prefix is handled by a different DHCP server. The client multicasts SOLICIT to all the DHCP servers. How does it collect all the addresses for different prefixes? Final case. Multiple DHCP server, all behind a relay. The relay has to be configured to unicast to each server in turn? Knowing the answers to these questions would be really useful at this point. Simon. ___ 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] Robustness in Homenet. (triggered by the DHCP-PD discussion).
Please, let's not OD on DHCP in this thread: while I was making a point about DHCP, I was really making a more general point about robustness in homenet, and how to judge various proposals, more than specifically attacking recursive DHCP-PD as a concept. Similarly, I think as another goal we have to accept easy debuggability as a goal. We need to know if a router is expected to function, and you should be able to easily see if the router is functioning *and* if can talk to its border routers and the rest of the Internet. One of the things I like about CeroWrt is that I can *always* talk to the router and from there I have a chance to figure out if it is able to talk to the rest of the home network, and the world (e.g. by seeing that I've got an IPv6 network delegation). Today, since we have to presume that you need a IPv4 address, this implies running a DHCP server on each router: in the long run, it's less than clear to me that this is desirable. But one way or the other, I've got to be able to connect and talk to the router to be able to debug it, preferably from both upstream and downstream directions. The CeroWrt router I'm debugging doesn't fate share with other routers to the point that you have no place to stand initially. So I'd expand my list of how to judge proposals to the configuration distribution problem to be: 1) robustness 2) hotplug 3) debuggability - Jim On Wed, Nov 14, 2012 at 8:31 AM, Simon Kelley si...@thekelleys.org.ukwrote: On 14/11/12 12:08, Teco Boot wrote: The one-and-only DHCP server knows about all the prefixes delegated from the ISP and the relays know which particular prefix has been given to the local router by the routing protocol or AHCP. I don't like a single DHCP server for multi-homed sites. This introduces unneeded complexity, it needs merging of information from multiple sources. This is completely incompatible with what MIF is doing (multiple provisioning domains). It also introduces an unneeded single point of failure. Multi-homing could be used for redundancy. Let's use a DHCP server for each ISP. In cases where a single CPE router connects to multiple ISPs, it can take two approaches: running multiple DHCP server instances, one for each ISP. Or perform the problematic integration. BRDP takes the per provisioning domain approach, where each provisioning domain is presented with a border router address (generated form provided prefix), with prefix length. Problem solved :-). OK. This raises some questions about DHCPv6 to which I don't know the answers. I hope Ted or someone else who was involved in the standard can answer. Simplest case first. Client and server on same link (in the RFC3315 definition of link) the server has an interface on the link which has multiple addresses with different prefixes, and it is configured to assign addresses on each of those prefixes. The client is unconfigured except for a link-local address. How does the client create a SOLICIT message which causes the server to reply with an ADVERTISE which offers the client an address with each of the prefixes ? The client doesn't know how many prefixes are available. Next case. The same as above but the SOLICIT transits via a relay. The relay can only insert one link address in the encapsulation, does the server have to know which prefixes share links so that it can determine which other prefixes are on the same link and reduce the problem to the case above? Next case. This speaks to Teco's suggestion. The same link with multiple prefixes, directly connected to servers, but now each prefix is handled by a different DHCP server. The client multicasts SOLICIT to all the DHCP servers. How does it collect all the addresses for different prefixes? Final case. Multiple DHCP server, all behind a relay. The relay has to be configured to unicast to each server in turn? Knowing the answers to these questions would be really useful at this point. Simon. ___ 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] Robustness in Homenet. (triggered by the DHCP-PD discussion).
On 14/11/12 16:24, Jim Gettys wrote: Please, let's not OD on DHCP in this thread: while I was making a point about DHCP, I was really making a more general point about robustness in homenet, and how to judge various proposals, more than specifically attacking recursive DHCP-PD as a concept. Similarly, I think as another goal we have to accept easy debuggability as a goal. We need to know if a router is expected to function, and you should be able to easily see if the router is functioning *and* if can talk to its border routers and the rest of the Internet. One of the things I like about CeroWrt is that I can *always* talk to the router and from there I have a chance to figure out if it is able to talk to the rest of the home network, and the world (e.g. by seeing that I've got an IPv6 network delegation). Today, since we have to presume that you need a IPv4 address, this implies running a DHCP server on each ^^ router: in the long run, it's less than clear to me that this is desirable. But one way or the other, I've got to be able to connect and talk to the router to be able to debug it, preferably from both upstream and downstream directions. The CeroWrt router I'm debugging doesn't fate share with other routers to the point that you have no place to stand initially. I agree with this, except the underlined section: DHCP-relay is a standard technique for DHCPv4. Simon. ___ 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
