Re: [homenet] regarding recursive DHCPv6-PD
On Thu, Nov 8, 2012 at 12:51 AM, Ralph Droms rdroms.i...@gmail.com wrote: Using PD in a home network isn't hard. Use a single delegating router; most obvious choice is the device that received the prefix from the external source. That doesn't work in a multihomed situation, though, right? Only if there is only one border router? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD
On Nov 19, 2012, at 3:47 AM, Lorenzo Colitti lore...@google.com wrote: That doesn't work in a multihomed situation, though, right? Only if there is only one border router? If there are two border routers, both advertise their prefixes. Hosts don't handle this particularly well, as we've discussed elsewhere, but it works just fine in terms of delivering service to the local network. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD
On Mon, Nov 19, 2012 at 5:47 AM, Ted Lemon mel...@fugue.com wrote: That doesn't work in a multihomed situation, though, right? Only if there is only one border router? If there are two border routers, both advertise their prefixes. Hosts don't handle this particularly well, as we've discussed elsewhere, but it works just fine in terms of delivering service to the local network. It's not just that. For example, if one of the border routers is unplugged, the hosts stay configured with invalid addresses until the lease expires. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
On 12/11/2012 17:33, Mark Townsley wrote: Nice to see a constructive thread with suggested text for the editors of the homenet arch, thank you. I'm concerned with any issue a warning type suggestions though. We are working hard to develop automatic configuration that assumes there is no operator involved here. If there is no operator to configure our protocols, there is no operator to issue a warning to either. If the homenet runs out of /64s to hand out, and we recommend not to route /128s, bridge, NPTv6, etc... then the final option is, simply, no IPv6 for that given link. Falling back to the user to try and interpret a cryptic message about IPv6 prefixes is simply not a realistic option for the protocols we are working on here. Which is a FAIL if there are any v6-only devices around. Ultimately I don't see how you can avoid some kind of warning to the user, even if it's the equivalent of the beeping from a smoke detector whose battery is fading. Brian - Mark On Nov 12, 2012, at 3:05 PM, Mattia Rossi wrote: If I'm the downstream router, I can't get a prefix, of course I issue warning message. However, if I'm the one who still get an /64 and works fine as a leaf, I won't issue an warning message for a fore-coming downstream router attached to me. So you have to implement a check and some sort of warning mechanism for not getting a PD anyways in all your devices (as I suspect that all of them could eventually be used as a downstream router). I don't think that it's much more difficult to check whether the PD was for a /64. You have to do that anyway, as your DHCP server won't be able to create a PD from a /64 and issue a warning in any case. So actually no real extra work needed there. non technical reason start The problem with having just the downstream router warning you though, is that in the case of multihoming, and two prefixes being provided to the homenet, one /64 from ISP1 and one /56 from ISP2, the downstream router might get them over the same interface, and simply issue no warning, as it's happy with the /56 from ISP2, and route everything over that ISP, without the user ever knowing. If the upstream router issues a warning about getting a /64 over an interface from an ISP, the user knows there's something wrong and can fix things, and avoid unnecessary high bills. /non technical reason end/ After the input of various posts I'd like to change the text in 3.4.1: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained (with IPv6 not reaching all devices in the home, or use of some form of IPv6 NAT being forced), or even unable to function. While it may be possible to operate a DHCPv6-only network with prefixes longer than /64, doing so would break SLAAC, and is thus not recommended. to the following text: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained. Attempting to use subnet prefixes longer than /64 would break SLAAC, and is thus not recommended. Using ULA prefixes internally with NPTv6 at the boundary would be possible, but is not recommended for reasons given elsewhere. Reverting to bridging would destroy subnetting, breaks multicast if bridged onto 802.11 wireless networks and has serious limitations with regard to heterogeneous link layer technologies and LLNs. For those reasons it is recommended that DHCP-PD or OSPFv3 capable routers have the ability to issue a warning upon receipt of a /64 if required to assign further prefixes within the home network as described in Section 3.4.3. Mat ___ 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] regarding recursive DHCPv6-PD (and architecture document)
Mark, I agree with what you say but that still means RPL could be on the table. It seems quite feasible to me that we could have a multi-link route-over subnet using a routing protocol such as RPL with downstream border routers as well. This may seem unlikely with an LLN but is more feasible with broader band link layer technologies. Granted, if multi-link route-over subnets are considered to exist only as leaf subnets (i.e. without downstream border routers) then life does get somewhat easier. The question is whether that is acceptable or not for the general picture. Robert On 12/11/2012 11:47 AM, Mark Townsley wrote: On Nov 10, 2012, at 2:21 AM, Robert Cragie wrote: On 09/11/2012 7:56 PM, Michael Richardson wrote: (and that's why RPL isn't on the table at homenet) RCCWhy not? Again, the sort of networks which would use RPL (LLNs) are referred to in the charter./RCC In the charter, LLNs are referred to as an example of a link-layer which might exist in the home and would accordingly require its own routed subnet, not that the entire home itself will be an LLN. - Mark ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org mailto:homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet smime.p7s Description: S/MIME Cryptographic Signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
On Nov 13, 2012, at 2:24 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: even if it's the equivalent of the beeping from a smoke detector whose battery is fading. To which the typical response is to throw the damned thing through the window out of rage after it's been beeping for a couple of hours. No, there are several viable solutions to this problem that don't involve beeping. Beeping is not the right solution. I would just like to point out, regarding the bufferbloat problem, that there are two classes of outcome if we hack around this problem instead of beeping. The first class of outcome is that something works less well than it otherwise would have. This is the bufferbloat problem. If you have bufferbloat because you set up a bridge where ideally you shouldn't have, this is bad, and the customer will experience less than ideal outcomes. But fundamentally, their network will function, particularly when loads are light. And so this becomes a problem that they will either live with, or try to solve, but it is not an emergency. It is a bad outcome, and the villain is clear: it's the ISP who gave out a /64. FAQs on the net can cast the blame appropriately, and the home gateway can provide diagnostics that explain why the situation is suboptimal. Contrast this with NAPTv6. In this case, the network is _broken_. End to end doesn't work. If you are not connected directly to the border gateway, certain protocols simply will not work. The result of this will be a general expectation on the part of applications vendors that end-to-end isn't something that can be counted upon. And so we will have got nothing for all our effort in deploying IPv6. We'll be back to NAT-inspired walled gardens. Let's at least set our sights on the better outcome: the one that preserves end to end. Yes, it's not ideal. But the blame will be cast on the correct villain, the end-user will at least have a chance of a good outcome, and it won't needlessly break end-to-end. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
On Nov 13, 2012, at 9:50 AM, Mattia Rossi mattia.rossi.mailingli...@gmail.com wrote: I still like the idea of a led which is red if no prefix could be received, orange if a /64 has been assigned, and a prefix has been requested from a downstream router (no prefix for the downstream router), and green if a prefix /64 has been assigned and a prefix has been requested from a downstream router and successfully provided. This is like the leds on the smoke detector, which start blinking once the battery level is low. They signal a problem, but it's up to the user whether to ignore it, or to fix it. I've got no argument with a notification mechanism like that, as long as we provide a clean mechanism for dealing with the case where the ISP doesn't provide as many bits of prefix as we need. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
On Tue, 13 Nov 2012, Mattia Rossi wrote: I still like the idea of a led which is red if no prefix could be received, orange if a /64 has been assigned, and a prefix has been requested from a downstream router (no prefix for the downstream router), and green if a prefix /64 has been assigned and a prefix has been requested from a downstream router and successfully provided. This sounds like a reasonable compromise. I am not a vendor manufacturer though, don't know the cost of this. This is like the leds on the smoke detector, which start blinking once the battery level is low. They signal a problem, but it's up to the user whether to ignore it, or to fix it. I don't know if it's local requirements, but my smoke detectors start chirping once every 5 minutes or so when they're low on battery. I don't want my home gateway to start doing that :P -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
If I'm the downstream router, I can't get a prefix, of course I issue warning message. However, if I'm the one who still get an /64 and works fine as a leaf, I won't issue an warning message for a fore-coming downstream router attached to me. So you have to implement a check and some sort of warning mechanism for not getting a PD anyways in all your devices (as I suspect that all of them could eventually be used as a downstream router). I don't think that it's much more difficult to check whether the PD was for a /64. You have to do that anyway, as your DHCP server won't be able to create a PD from a /64 and issue a warning in any case. So actually no real extra work needed there. non technical reason start The problem with having just the downstream router warning you though, is that in the case of multihoming, and two prefixes being provided to the homenet, one /64 from ISP1 and one /56 from ISP2, the downstream router might get them over the same interface, and simply issue no warning, as it's happy with the /56 from ISP2, and route everything over that ISP, without the user ever knowing. If the upstream router issues a warning about getting a /64 over an interface from an ISP, the user knows there's something wrong and can fix things, and avoid unnecessary high bills. /non technical reason end/ After the input of various posts I'd like to change the text in 3.4.1: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained (with IPv6 not reaching all devices in the home, or use of some form of IPv6 NAT being forced), or even unable to function. While it may be possible to operate a DHCPv6-only network with prefixes longer than /64, doing so would break SLAAC, and is thus not recommended. to the following text: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained. Attempting to use subnet prefixes longer than /64 would break SLAAC, and is thus not recommended. Using ULA prefixes internally with NPTv6 at the boundary would be possible, but is not recommended for reasons given elsewhere. Reverting to bridging would destroy subnetting, breaks multicast if bridged onto 802.11 wireless networks and has serious limitations with regard to heterogeneous link layer technologies and LLNs. For those reasons it is recommended that DHCP-PD or OSPFv3 capable routers have the ability to issue a warning upon receipt of a /64 if required to assign further prefixes within the home network as described in Section 3.4.3. Mat ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
mike == mike m...@mtcc.com writes: Michael Does that apply to my Android phone too? Are you asking if your Android phone, when it gets only /64 from LTE/3G provider, should hand that out, and then indicate out of /64s? Yes. The phone has a pretty clear way to indicate this problem to the user. mike I'm asking about whether I should expect my android phone to get a /56. mike My phone is, after all, capable of being a router. I'm somehow guessing that mike phone isp's aren't giving out /56's though. So far, they aren't giving out anything. Perhaps we can encourage 3G terminals to be able to be configured as to how much address space they ask for a nice slider :-) -- Michael Richardson -on the road- pgpkikrLaey8Q.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
On Nov 10, 2012, at 2:21 AM, Robert Cragie wrote: On 09/11/2012 7:56 PM, Michael Richardson wrote: (and that's why RPL isn't on the table at homenet) RCCWhy not? Again, the sort of networks which would use RPL (LLNs) are referred to in the charter./RCC In the charter, LLNs are referred to as an example of a link-layer which might exist in the home and would accordingly require its own routed subnet, not that the entire home itself will be an LLN. - Mark ___ 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] regarding recursive DHCPv6-PD (and architecture document)
Nice to see a constructive thread with suggested text for the editors of the homenet arch, thank you. I'm concerned with any issue a warning type suggestions though. We are working hard to develop automatic configuration that assumes there is no operator involved here. If there is no operator to configure our protocols, there is no operator to issue a warning to either. If the homenet runs out of /64s to hand out, and we recommend not to route /128s, bridge, NPTv6, etc... then the final option is, simply, no IPv6 for that given link. Falling back to the user to try and interpret a cryptic message about IPv6 prefixes is simply not a realistic option for the protocols we are working on here. - Mark On Nov 12, 2012, at 3:05 PM, Mattia Rossi wrote: If I'm the downstream router, I can't get a prefix, of course I issue warning message. However, if I'm the one who still get an /64 and works fine as a leaf, I won't issue an warning message for a fore-coming downstream router attached to me. So you have to implement a check and some sort of warning mechanism for not getting a PD anyways in all your devices (as I suspect that all of them could eventually be used as a downstream router). I don't think that it's much more difficult to check whether the PD was for a /64. You have to do that anyway, as your DHCP server won't be able to create a PD from a /64 and issue a warning in any case. So actually no real extra work needed there. non technical reason start The problem with having just the downstream router warning you though, is that in the case of multihoming, and two prefixes being provided to the homenet, one /64 from ISP1 and one /56 from ISP2, the downstream router might get them over the same interface, and simply issue no warning, as it's happy with the /56 from ISP2, and route everything over that ISP, without the user ever knowing. If the upstream router issues a warning about getting a /64 over an interface from an ISP, the user knows there's something wrong and can fix things, and avoid unnecessary high bills. /non technical reason end/ After the input of various posts I'd like to change the text in 3.4.1: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained (with IPv6 not reaching all devices in the home, or use of some form of IPv6 NAT being forced), or even unable to function. While it may be possible to operate a DHCPv6-only network with prefixes longer than /64, doing so would break SLAAC, and is thus not recommended. to the following text: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained. Attempting to use subnet prefixes longer than /64 would break SLAAC, and is thus not recommended. Using ULA prefixes internally with NPTv6 at the boundary would be possible, but is not recommended for reasons given elsewhere. Reverting to bridging would destroy subnetting, breaks multicast if bridged onto 802.11 wireless networks and has serious limitations with regard to heterogeneous link layer technologies and LLNs. For those reasons it is recommended that DHCP-PD or OSPFv3 capable routers have the ability to issue a warning upon receipt of a /64 if required to assign further prefixes within the home network as described in Section 3.4.3. Mat ___ 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] regarding recursive DHCPv6-PD (and architecture document)
Mark == Mark Townsley m...@townsley.net writes: Mark I'm concerned with any issue a warning type suggestions Mark though. We are working hard to develop automatic configuration Mark that assumes there is no operator involved here. If there is Mark no operator to configure our protocols, there is no operator Mark to issue a warning to either. okay. Can we define a DHCP request, which is really a request for the ISP to log something from that customer? i.e. can we tunnel syslog through dhcp? :-) Or shall we suggest homenet routers ask the ISP for a syslog server, and log things there? (do we have a dhcp option to describe syslog server... a grep of RFCs doesn't find one, and rfc5424 doesn't mention one) In particular, for ISP provided routers, this would make lots of sense. -- Michael Richardson -on the road- pgpqbl0twP55f.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
On Nov 9, 2012 3:30 PM, mike m...@mtcc.com wrote: On 11/9/12 3:21 PM, Michael Richardson wrote: Michael == Michael Thomas m...@mtcc.com writes: An ISP that gives out a single /64 is broken. As long as we have a way to indicate out of /64s (because that could happen, even if you are given a /48, and have some pathology...), then we are good. Michael Does that apply to my Android phone too? Are you asking if your Android phone, when it gets only /64 from LTE/3G provider, should hand that out, and then indicate out of /64s? Yes. The phone has a pretty clear way to indicate this problem to the user. I'm asking about whether I should expect my android phone to get a /56. My phone is, after all, capable of being a router. I'm somehow guessing that phone isp's aren't giving out /56's though. Mike This case is looked at in v6ops http://tools.ietf.org/html/draft-byrne-v6ops-64share-03 The simple answer is that there is a deployment lag issue. Neither Android nor the mobile networks support PD today. But they can and will support pd in time. CB ___ 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] regarding recursive DHCPv6-PD (and architecture document)
Proxy-ND doesn't seem hard... much less evil than NAT, after all. Andrew On 9/11/2012, at 2:56 PM, Michael Richardson mcr+i...@sandelman.ca wrote: Andrew == Andrew McGregor andrewm...@gmail.com writes: Andrew This whole thread is making me think that specifying that we Andrew use either babel (with attention to getting it documented Andrew properly) or one of the OSPFv4 MANET extensions, in the case Andrew where we have only a /64 and perhaps any time we find we Andrew have an 802.11s, ad-hoc or NBMA interface in play. That way Andrew we introduce /128 routes, and everything continues to work. so, great maybe, except that now either: 1) hosts have to participate in the routing protocol. (so impact on hosts) 2) we have to deploy proxy-ND. (and that's why RPL isn't on the table at homenet) -- Michael Richardson -on the road- ___ 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] regarding recursive DHCPv6-PD (and architecture document)
Cameron Byrne wrote: On Nov 9, 2012 3:30 PM, mike m...@mtcc.com mailto:m...@mtcc.com wrote: This case is looked at in v6ops http://tools.ietf.org/html/draft-byrne-v6ops-64share-03 The simple answer is that there is a deployment lag issue. Neither Android nor the mobile networks support PD today. But they can and will support pd in time. I expect that there well may be resistance as wireline-ISP's have come to expect that there's a router in home. I very much doubt they view phones as anything other than hosts except when they can charge outrageous fees for tethering. Which sort of brings up the obvious question: if ISP's don't cooperate, what will people do to route around the damage, especially in the face of all the unused space of a /64 they can poach. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
Op 10 nov. 2012, om 00:30 heeft mike het volgende geschreven: On 11/9/12 3:21 PM, Michael Richardson wrote: Michael == Michael Thomas m...@mtcc.com writes: An ISP that gives out a single /64 is broken. As long as we have a way to indicate out of /64s (because that could happen, even if you are given a /48, and have some pathology...), then we are good. Michael Does that apply to my Android phone too? Are you asking if your Android phone, when it gets only /64 from LTE/3G provider, should hand that out, and then indicate out of /64s? Yes. The phone has a pretty clear way to indicate this problem to the user. I'm asking about whether I should expect my android phone to get a /56. My phone is, after all, capable of being a router. I'm somehow guessing that phone isp's aren't giving out /56's though. Maybe. Maybe not. My phone supports three tethering interfaces already. My provider supports tethering. No IPv6 yet. Any idea how multi-interface tethering is supported with single /64, without proxy-ND, without translation? We could stop writing how /64 could work, with hacks. Better describe the clean way of doing, and publish lots on bad things that happen with /64 PD to customers. 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] regarding recursive DHCPv6-PD (and architecture document)
Am 08.11.2012 20:04, schrieb Michael Richardson: Mattia == Mattia Rossi mattia.rossi.mailingli...@gmail.com writes: In a lot of these conversations, the lightswitch guys (as someone called the LLN proponents) seem to get forgotten. Mattia So what happens if the lightswitch guys want to plug-in a Mattia router, which they have to, as they can't bridge, but Mattia there's only one exit router from one ISP which is managed Mattia and gets a /64 only? SLAAC relay? I think in this case a Mattia /64 is simply not acceptable. The lights work in the home (because routing of ULA works fine) Possibly, you can't control them from outside the home. So, ISP that gives out /56 has an obvious way to demonstrate why they suck less than /64-only ISP. This is exactly the message that should be conveyed by the draft It is not clear that all LLNs will even want globally routable address space. Some will. Some won't know what to do with it. I agree on that. That's why I took the case where they want globally routable addresses to remote control each single light (or sensor - which might sound more plausible to some folks). If the lights just need to communicate within the homenet, ULA's do the job. And as you say, they might even be the better solution. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
Am 08.11.2012 21:40, schrieb Robert Cragie: Just to be clear - using a /64 will not necessarily break a home network with a LLN. It's just that some kludge will be needed and the least preferable IMHO for LLNs is bridging. Yes, I agree, and you can't force the LLN routers to be some high-end routers able to do all the necessary magic to work around the problems due to the assignment of a /64 from the ISP. So I would suggest something like: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained. Attempting to use subnet prefixes longer than /64 would break SLAAC, and is thus not recommended. Using ULA prefixes internally with NPTv6 at the boundary would be possible, but is not recommended for reasons given elsewhere. Another solution would be for the internal routers to revert to bridging mode, even though this would destroy the benefits of subnetting and has serious limitations with regard to heterogeneous link layer technologies and LLNs. I prefer your text :-) Mat ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
Am 08.11.2012 21:03, schrieb Hans Liu: On Fri, Nov 9, 2012 at 3:40 AM, Ray Bellis ray.bel...@nominet.org.uk wrote: On 8 Nov 2012, at 14:28, Ted Lemon mel...@fugue.com wrote: Sure, but log a system management error is not something that a home router vendor can meaningfully implement, unless it puts a speaker in the home router and has it start bellowing out of addresses in every known language. But the real problem is that this signal, even if received, will be misinterpreted as router is broken, return to Home Despot and replace with one that isn't broken. no hat I note that the Apple Airport Utility pops up warnings about various errors, some of which relate to sub-optimal network configuration, rather than misconfiguration. In particular, they warn you if you try to use double NAT. Users can acknowledge those warnings, so they no longer appear. I can envisage a box issuing a similar warning if it only gets a /64 from its upstream. As a CPE vendor, I don't think I'd design my product this way. I won't have my router to issue a warning if it only gets a /64 from its upstream. The reason? Users see a warning in either log or LED, they call either the operator or my customer service. I really don't want to say so but the one that will face a problem is the downstream router, and that's not my problem. Your CPE router could be the downstream router. The user buys it, plugs it in, doesn't work. No warning, nothing. He throws it out, even if it's not your fault, and never buys anything from your company again. How's that for a scenario? Mat ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
Sent from Hans' iPad2 On Nov 9, 2012, at 4:20 PM, Mattia Rossi mattia.rossi.mailingli...@gmail.com wrote: Am 08.11.2012 21:03, schrieb Hans Liu: On Fri, Nov 9, 2012 at 3:40 AM, Ray Bellis ray.bel...@nominet.org.uk wrote: On 8 Nov 2012, at 14:28, Ted Lemon mel...@fugue.com wrote: Sure, but log a system management error is not something that a home router vendor can meaningfully implement, unless it puts a speaker in the home router and has it start bellowing out of addresses in every known language. But the real problem is that this signal, even if received, will be misinterpreted as router is broken, return to Home Despot and replace with one that isn't broken. no hat I note that the Apple Airport Utility pops up warnings about various errors, some of which relate to sub-optimal network configuration, rather than misconfiguration. In particular, they warn you if you try to use double NAT. Users can acknowledge those warnings, so they no longer appear. I can envisage a box issuing a similar warning if it only gets a /64 from its upstream. As a CPE vendor, I don't think I'd design my product this way. I won't have my router to issue a warning if it only gets a /64 from its upstream. The reason? Users see a warning in either log or LED, they call either the operator or my customer service. I really don't want to say so but the one that will face a problem is the downstream router, and that's not my problem. Your CPE router could be the downstream router. The user buys it, plugs it in, doesn't work. No warning, nothing. He throws it out, even if it's not your fault, and never buys anything from your company again. How's that for a scenario? If I'm the downstream router, I can't get a prefix, of course I issue warning message. However, if I'm the one who still get an /64 and works fine as a leaf, I won't issue an warning message for a fore-coming downstream router attached to me. Mat ___ 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] regarding recursive DHCPv6-PD (and architecture document)
Op 9 nov. 2012, om 09:00 heeft Mattia Rossi het volgende geschreven: Am 08.11.2012 20:04, schrieb Michael Richardson: Mattia == Mattia Rossi mattia.rossi.mailingli...@gmail.com writes: In a lot of these conversations, the lightswitch guys (as someone called the LLN proponents) seem to get forgotten. Mattia So what happens if the lightswitch guys want to plug-in a Mattia router, which they have to, as they can't bridge, but Mattia there's only one exit router from one ISP which is managed Mattia and gets a /64 only? SLAAC relay? I think in this case a Mattia /64 is simply not acceptable. The lights work in the home (because routing of ULA works fine) Possibly, you can't control them from outside the home. So, ISP that gives out /56 has an obvious way to demonstrate why they suck less than /64-only ISP. This is exactly the message that should be conveyed by the draft It is not clear that all LLNs will even want globally routable address space. Some will. Some won't know what to do with it. I agree on that. That's why I took the case where they want globally routable addresses to remote control each single light (or sensor - which might sound more plausible to some folks). If the lights just need to communicate within the homenet, ULA's do the job. And as you say, they might even be the better solution. I expect a controller, with global address. This enables control from outside. Other solution: VPN for back to my home. 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] regarding recursive DHCPv6-PD (and architecture document)
I note that the Apple Airport Utility pops up warnings about various errors, some of which relate to sub-optimal network configuration, rather than misconfiguration. In particular, they warn you if you try to use double NAT. it seems to me that we ought to ask Apple^WStuart how these warnings are communicated from AirPort to laptop, and ask them if they would like to contribute a document to homenet to standardized such a protocol. (are they in DHCP? RAs? mDNS? something weirder?) -- Michael Richardson -on the road- pgpeb1WYKHUhM.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
Andrew == Andrew McGregor andrewm...@gmail.com writes: Andrew This whole thread is making me think that specifying that we Andrew use either babel (with attention to getting it documented Andrew properly) or one of the OSPFv4 MANET extensions, in the case Andrew where we have only a /64 and perhaps any time we find we Andrew have an 802.11s, ad-hoc or NBMA interface in play. That way Andrew we introduce /128 routes, and everything continues to work. so, great maybe, except that now either: 1) hosts have to participate in the routing protocol. (so impact on hosts) 2) we have to deploy proxy-ND. (and that's why RPL isn't on the table at homenet) -- Michael Richardson -on the road- pgpldkdCvNgVD.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
Teco == Teco Boot t...@inf-net.nl writes: Mattia So what happens if the lightswitch guys want to plug-in a Mattia router, which they have to, as they can't bridge, but Mattia there's only one exit router from one ISP which is managed Mattia and gets a /64 only? SLAAC relay? I think in this case a Mattia /64 is simply not acceptable. The lights work in the home (because routing of ULA works fine) Possibly, you can't control them from outside the home. So, ISP that gives out /56 has an obvious way to demonstrate why they suck less than /64-only ISP. This is exactly the message that should be conveyed by the draft It is not clear that all LLNs will even want globally routable address space. Some will. Some won't know what to do with it. I agree on that. That's why I took the case where they want globally routable addresses to remote control each single light (or sensor - which might sound more plausible to some folks). If the lights just need to communicate within the homenet, ULA's do the job. And as you say, they might even be the better solution. Teco I expect a controller, with global address. This enables Teco control from outside. Other solution: VPN for back to my home. In a simple home, the controller is on the one LAN which got the /64, and so that side of it is accessible anyway. -- Michael Richardson -on the road- pgpVxkazNhUhR.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
On 09/11/2012 7:56 PM, Michael Richardson wrote: (and that's why RPL isn't on the table at homenet) RCCWhy not? Again, the sort of networks which would use RPL (LLNs) are referred to in the charter./RCC ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet smime.p7s Description: S/MIME Cryptographic Signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD
Well, being a residential CPE vendor, I can confirm some of our customers deploy /64 only to the CPE. Not recommended by us, but being a managed CPE, it's the customer making the final decision on this. Regs Carl -Original Message- From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf Of Mikael Abrahamsson Sent: woensdag 7 november 2012 19:07 To: Andrew McGregor Cc: homenet@ietf.org Group; Ted Lemon; Ralph Droms Subject: Re: [homenet] regarding recursive DHCPv6-PD On Wed, 7 Nov 2012, Andrew McGregor wrote: But that's single-delegating-router, not recursive. The problem with recursive is figuring out what prefix length a sub-delegating router is going to ask for from its upstream. For a single-delegating-router setup, you just ask for either a bunch of /64s or something that just contains enough of those to cover all your downstream interfaces. In a recursive situation, you don't know what you will need further downstream. For me, I've always taken for granted that the ISP CPE gets a /56 or something, and then it's fine to subdelegate /64s out of that as needed, and subdelegating routers request a /64 at a time as needed, and relay for sub-sub-delegating routers (as OP suggested). The hard part is to get the source based routing to work so that packets flowing upstream exit via the correct ISP CPE (if the home is multihomed to multiple ISPs) depending on what source address they have, so as to avoid getting dropped by uRPF filters. I'm surprised the subnet allocation size is still being discussed, I haven't followed the working group as closely as I should, but I hope we can get through this quickly. -- 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] regarding recursive DHCPv6-PD
On 08/11/2012 09:48, Mikael Abrahamsson wrote: On Thu, 8 Nov 2012, Wuyts Carl wrote: Well, being a residential CPE vendor, I can confirm some of our customers deploy /64 only to the CPE. Not recommended by us, but being a managed CPE, it's the customer making the final decision on this. If they only give the end user a /64, then the end customer won't be able to have a multi-LAN routed home. Hopefully the end customer will switch ISPs to one that isn't so restrictive. Fine, but when such an end customer buys a second router and plugs it in, will she get an error message that says Please find a new ISP? This is not intended as a frivolous question. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
On 08/11/2012 12:05, Ted Lemon wrote: On Nov 8, 2012, at 6:41 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Fine, but when such an end customer buys a second router and plugs it in, will she get an error message that says Please find a new ISP? In this case I think our only option is to fall back to bridging. Without some fundamental surgery on the IPv6 specs, I fear that is true, so does it have to become (gulp) a feature of the homenet architecture? I would hate that but at the moment I see no alternative. There is another alternative, routed ULA within the homenet and NPTv6 at the border, but we've already said we don't want to recommend that. I think the following paragraph of the architecture document needs to be revised accordingly: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained (with IPv6 not reaching all devices in the home, or use of some form of IPv6 NAT being forced), or even unable to function. While it may be possible to operate a DHCPv6-only network with prefixes longer than /64, doing so would break SLAAC, and is thus not recommended. Something like: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained. Attempting to use subnet prefixes longer than /64 would break SLAAC, and is thus not recommended. Using ULA prefixes internally with NPTv6 at the boundary would be possible, but is not recommended for reasons given elsewhere. The least damaging solution would be for the internal routers to revert to bridging mode, even though this would destroy the benefits of subnetting. Brian Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD
On Thu, 8 Nov 2012, Ted Lemon wrote: On Nov 8, 2012, at 6:41 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Fine, but when such an end customer buys a second router and plugs it in, will she get an error message that says Please find a new ISP? In this case I think our only option is to fall back to bridging. Yes, doing protocol based brinding (L2 bridge 0x86dd packets) is the only way to go as far as I can tell. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
On Thu, 8 Nov 2012, Robert Cragie wrote: In a lot of these conversations, the lightswitch guys (as someone called the LLN proponents) seem to get forgotten. So let's just say that giving a single /64 to the home is incompatible with homenet architecture, and we need more addresses. I'm fine with that. I see little reason to support /64 for homenet, because if there is only a single subnet, there is not much to network with within the home, there is only a single subnet. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
On 08/11/2012 12:25 PM, Brian E Carpenter wrote: On 08/11/2012 12:05, Ted Lemon wrote: On Nov 8, 2012, at 6:41 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Fine, but when such an end customer buys a second router and plugs it in, will she get an error message that says Please find a new ISP? In this case I think our only option is to fall back to bridging. Without some fundamental surgery on the IPv6 specs, I fear that is true, so does it have to become (gulp) a feature of the homenet architecture? I would hate that but at the moment I see no alternative. There is another alternative, routed ULA within the homenet and NPTv6 at the border, but we've already said we don't want to recommend that. I think the following paragraph of the architecture document needs to be revised accordingly: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained (with IPv6 not reaching all devices in the home, or use of some form of IPv6 NAT being forced), or even unable to function. While it may be possible to operate a DHCPv6-only network with prefixes longer than /64, doing so would break SLAAC, and is thus not recommended. Something like: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained. Attempting to use subnet prefixes longer than /64 would break SLAAC, and is thus not recommended. Using ULA prefixes internally with NPTv6 at the boundary would be possible, but is not recommended for reasons given elsewhere. The least damaging solution would be for the internal routers to revert to bridging mode, even though this would destroy the benefits of subnetting. I don't think bridging should be considered for homenet. Don't forget the following in the charter: Also, link layer networking technology is poised to become more heterogeneous, as networks begin to employ both traditional Ethernet technology and link layers designed for low-powered sensor networks. In a lot of these conversations, the lightswitch guys (as someone called the LLN proponents) seem to get forgotten. So what happens if the lightswitch guys want to plug-in a router, which they have to, as they can't bridge, but there's only one exit router from one ISP which is managed and gets a /64 only? SLAAC relay? I think in this case a /64 is simply not acceptable. Mat ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
On 08/11/2012 13:45, Mattia Rossi wrote: On 08/11/2012 12:25 PM, Brian E Carpenter wrote: On 08/11/2012 12:05, Ted Lemon wrote: On Nov 8, 2012, at 6:41 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Fine, but when such an end customer buys a second router and plugs it in, will she get an error message that says Please find a new ISP? In this case I think our only option is to fall back to bridging. Without some fundamental surgery on the IPv6 specs, I fear that is true, so does it have to become (gulp) a feature of the homenet architecture? I would hate that but at the moment I see no alternative. There is another alternative, routed ULA within the homenet and NPTv6 at the border, but we've already said we don't want to recommend that. I think the following paragraph of the architecture document needs to be revised accordingly: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained (with IPv6 not reaching all devices in the home, or use of some form of IPv6 NAT being forced), or even unable to function. While it may be possible to operate a DHCPv6-only network with prefixes longer than /64, doing so would break SLAAC, and is thus not recommended. Something like: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained. Attempting to use subnet prefixes longer than /64 would break SLAAC, and is thus not recommended. Using ULA prefixes internally with NPTv6 at the boundary would be possible, but is not recommended for reasons given elsewhere. The least damaging solution would be for the internal routers to revert to bridging mode, even though this would destroy the benefits of subnetting. I don't think bridging should be considered for homenet. Don't forget the following in the charter: Also, link layer networking technology is poised to become more heterogeneous, as networks begin to employ both traditional Ethernet technology and link layers designed for low-powered sensor networks. In a lot of these conversations, the lightswitch guys (as someone called the LLN proponents) seem to get forgotten. So what happens if the lightswitch guys want to plug-in a router, which they have to, as they can't bridge, but there's only one exit router from one ISP which is managed and gets a /64 only? SLAAC relay? I think in this case a /64 is simply not acceptable. OK, so there are failure cases and that too needs to be stated in the architecture. Send text. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
On 08/11/2012 13:41, Mikael Abrahamsson wrote: On Thu, 8 Nov 2012, Robert Cragie wrote: In a lot of these conversations, the lightswitch guys (as someone called the LLN proponents) seem to get forgotten. So let's just say that giving a single /64 to the home is incompatible with homenet architecture, and we need more addresses. I'm fine with that. I see little reason to support /64 for homenet, because if there is only a single subnet, there is not much to network with within the home, there is only a single subnet. I wish I could agree. But if we don't provide for this situation in the architecture, we are simply ignoring a segment of the real world, and that is unrealistic. We need to design things so that if a homenet user switches between a /56 ISP and a /64 ISP, stuff just reconfigures itself to bridging mode (and any boxes that can't do that report the problem in an intelligible way). Also consider a dual-homed homenet where one ISP gives a /64 and the other gives a /56. I guess that has to revert to bridging mode too. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
Comment inline. Robert On 08/11/2012 12:25 PM, Brian E Carpenter wrote: On 08/11/2012 12:05, Ted Lemon wrote: On Nov 8, 2012, at 6:41 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Fine, but when such an end customer buys a second router and plugs it in, will she get an error message that says Please find a new ISP? In this case I think our only option is to fall back to bridging. Without some fundamental surgery on the IPv6 specs, I fear that is true, so does it have to become (gulp) a feature of the homenet architecture? I would hate that but at the moment I see no alternative. There is another alternative, routed ULA within the homenet and NPTv6 at the border, but we've already said we don't want to recommend that. I think the following paragraph of the architecture document needs to be revised accordingly: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained (with IPv6 not reaching all devices in the home, or use of some form of IPv6 NAT being forced), or even unable to function. While it may be possible to operate a DHCPv6-only network with prefixes longer than /64, doing so would break SLAAC, and is thus not recommended. Something like: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained. Attempting to use subnet prefixes longer than /64 would break SLAAC, and is thus not recommended. Using ULA prefixes internally with NPTv6 at the boundary would be possible, but is not recommended for reasons given elsewhere. The least damaging solution would be for the internal routers to revert to bridging mode, even though this would destroy the benefits of subnetting. RCCI think it is arguable whether bridging is the least damaging solution. It fundamentally does not work with route-over multi-link subnets and would therefore require some extra L2 weirdness at a LLN border router. If ISPs are going to hobble us with /64s then I think you will find NPTv6 solutions appearing for the same reason NAT is used today. There are alternatives but, as noted in the architecture draft, these break SLAAC. So I think the onus is to push back on ISPs ofering /64s if we want to avoid any kludges./RCC Brian Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet smime.p7s Description: S/MIME Cryptographic Signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
HI, So let's just say that giving a single /64 to the home is incompatible with homenet architecture, and we need more addresses. I'm fine with that. Yes please. I think some ISPs *need* to get a signal like this. Sander ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
even though this would destroy the benefits of subnetting. RCCI think it is arguable whether bridging is the least damaging solution. It fundamentally does not work with route-over multi-link subnets and would therefore require some extra L2 weirdness at a LLN border router. If ISPs are going to hobble us with /64s then I think you will find NPTv6 solutions appearing for the same reason NAT is used today. There are alternatives but, as noted in the architecture draft, these break SLAAC. So I think the onus is to push back on ISPs ofering /64s if we want to avoid any kludges./RCC Just to further some of the comments I made yesterday. I understand the we don¹t want a /64 to show up, but this may occur for reasons other then the primary intention of the ISP. Many things occur in a network - IP depletion/low avail blocks, errors, mis-configuration etc. No matter why it occurs, ignoring this case is likely not a good idea. I agree with earlier comments that this can be considered as a failure mode. It still needs to be considered for good engineering on how CPEs and homenet gear will behave. Regards, Victor Kuarsingh ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
Mattia == Mattia Rossi mattia.rossi.mailingli...@gmail.com writes: Mattia might become: Mattia The home network needs to be adaptable to such ISP Mattia policies, and thus make no assumptions about the stability Mattia of the prefix received from an ISP, or the length of the Mattia prefix that may be offered. However, if only a /64 is Mattia offered by the ISP, the homenet may be severely Mattia constrained. Attempting to use subnet prefixes longer than Mattia /64 would break SLAAC, and is thus not recommended. Using Mattia ULA prefixes internally with NPTv6 at the boundary would be Mattia possible, but is not recommended for reasons given Mattia elsewhere. The least damaging solution would be for the Mattia internal routers to revert to bridging mode, even though Mattia this would destroy the benefits of subnetting. There are I am opposed to this text. Mattia cases where neither bridging mode nor NPTv6, nor DHCPv6 are Mattia feasible, e.g. if there are LLN subnets within the homenet Mattia which require remote access. In such cases a /64 assignment Mattia from an ISP will break the home network, and should Mattia therefore be avoided. please remember that multicast is hostile to plain wifi, and regularly breaks it, if you bridge wired to wireless. -- Michael Richardson -on the road- pgp6i99IQjO0G.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
Brian == Brian E Carpenter brian.e.carpen...@gmail.com writes: Yes please. I think some ISPs *need* to get a signal like this. Brian Sure, but that does *not* excuse us from specifying how the Brian end user gets service in such a situation. so, lets' say you come home with a new fancy router... and you discover that haven't got an electrical outlet to plug it into. Should we solve that problem too? (as homework: are power bars NAT's, Routers, or Bridges?) -- Michael Richardson -on the road- pgpC2pDMskTZW.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
On Nov 8, 2012, at 2:11 PM, Michael Richardson mcr+i...@sandelman.ca wrote: interfaces, the IPv6 CE router SHOULD log a system management error. it doesn't tell us to start bridging. Sure, but log a system management error is not something that a home router vendor can meaningfully implement, unless it puts a speaker in the home router and has it start bellowing out of addresses in every known language. But the real problem is that this signal, even if received, will be misinterpreted as router is broken, return to Home Despot and replace with one that isn't broken. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
On Nov 8, 2012, at 2:40 PM, Ray Bellis ray.bel...@nominet.org.uk wrote: I note that the Apple Airport Utility pops up warnings about various errors, some of which relate to sub-optimal network configuration, rather than misconfiguration. In particular, they warn you if you try to use double NAT. This is very cool, but even people I know who have Airport base stations frequently have no idea what to do about these warnings, and most people don't have Airport base stations—they have stupidly cheap Linsky routers. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
On Fri, Nov 9, 2012 at 3:40 AM, Ray Bellis ray.bel...@nominet.org.uk wrote: On 8 Nov 2012, at 14:28, Ted Lemon mel...@fugue.com wrote: Sure, but log a system management error is not something that a home router vendor can meaningfully implement, unless it puts a speaker in the home router and has it start bellowing out of addresses in every known language. But the real problem is that this signal, even if received, will be misinterpreted as router is broken, return to Home Despot and replace with one that isn't broken. no hat I note that the Apple Airport Utility pops up warnings about various errors, some of which relate to sub-optimal network configuration, rather than misconfiguration. In particular, they warn you if you try to use double NAT. Users can acknowledge those warnings, so they no longer appear. I can envisage a box issuing a similar warning if it only gets a /64 from its upstream. As a CPE vendor, I don't think I'd design my product this way. I won't have my router to issue a warning if it only gets a /64 from its upstream. The reason? Users see a warning in either log or LED, they call either the operator or my customer service. I really don't want to say so but the one that will face a problem is the downstream router, and that's not my problem. Sincerely, Hans It would be nice if there was a generic method for doing this that was vendor independent, but I guess that's unlikely to happen. Ray ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Instead of following the fashion, we lead it through. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
This whole thread is making me think that specifying that we use either babel (with attention to getting it documented properly) or one of the OSPFv4 MANET extensions, in the case where we have only a /64 and perhaps any time we find we have an 802.11s, ad-hoc or NBMA interface in play. That way we introduce /128 routes, and everything continues to work. Andrew On 8/11/2012, at 10:51 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 08/11/2012 15:09, Victor Kuarsingh wrote: even though this would destroy the benefits of subnetting. RCCI think it is arguable whether bridging is the least damaging solution. It fundamentally does not work with route-over multi-link subnets and would therefore require some extra L2 weirdness at a LLN border router. If ISPs are going to hobble us with /64s then I think you will find NPTv6 solutions appearing for the same reason NAT is used today. There are alternatives but, as noted in the architecture draft, these break SLAAC. So I think the onus is to push back on ISPs ofering /64s if we want to avoid any kludges./RCC Just to further some of the comments I made yesterday. I understand the we don¹t want a /64 to show up, but this may occur for reasons other then the primary intention of the ISP. Many things occur in a network - IP depletion/low avail blocks, errors, mis-configuration etc. No matter why it occurs, ignoring this case is likely not a good idea. I agree with earlier comments that this can be considered as a failure mode. It still needs to be considered for good engineering on how CPEs and homenet gear will behave. Exactly. It would be very bad for the end users to ignore this reality. On 08/11/2012 15:02, Sander Steffann wrote: So let's just say that giving a single /64 to the home is incompatible with homenet architecture, and we need more addresses. I'm fine with that. Yes please. I think some ISPs *need* to get a signal like this. Sure, but that does *not* excuse us from specifying how the end user gets service in such a situation. Brian ___ 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] regarding recursive DHCPv6-PD (and architecture document)
Can this be generalized for anytime a prefix offered is not large enough to cover the number of interfaces? On 11/8/12 3:40 PM, Robert Cragie robert.cra...@gridmerge.com wrote: Just to be clear - using a /64 will not necessarily break a home network with a LLN. It's just that some kludge will be needed and the least preferable IMHO for LLNs is bridging. So I would suggest something like: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained. Attempting to use subnet prefixes longer than /64 would break SLAAC, and is thus not recommended. Using ULA prefixes internally with NPTv6 at the boundary would be possible, but is not recommended for reasons given elsewhere. Another solution would be for the internal routers to revert to bridging mode, even though this would destroy the benefits of subnetting and has serious limitations with regard to heterogeneous link layer technologies and LLNs. Robert On 08/11/2012 4:15 PM, Mattia Rossi wrote: I don't think bridging should be considered for homenet. Don't forget the following in the charter: Also, link layer networking technology is poised to become more heterogeneous, as networks begin to employ both traditional Ethernet technology and link layers designed for low-powered sensor networks. In a lot of these conversations, the lightswitch guys (as someone called the LLN proponents) seem to get forgotten. So what happens if the lightswitch guys want to plug-in a router, which they have to, as they can't bridge, but there's only one exit router from one ISP which is managed and gets a /64 only? SLAAC relay? I think in this case a /64 is simply not acceptable. OK, so there are failure cases and that too needs to be stated in the architecture. Send text. So your text: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained. Attempting to use subnet prefixes longer than /64 would break SLAAC, and is thus not recommended. Using ULA prefixes internally with NPTv6 at the boundary would be possible, but is not recommended for reasons given elsewhere. The least damaging solution would be for the internal routers to revert to bridging mode, even though this would destroy the benefits of subnetting. might become: The home network needs to be adaptable to such ISP policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. However, if only a /64 is offered by the ISP, the homenet may be severely constrained. Attempting to use subnet prefixes longer than /64 would break SLAAC, and is thus not recommended. Using ULA prefixes internally with NPTv6 at the boundary would be possible, but is not recommended for reasons given elsewhere. The least damaging solution would be for the internal routers to revert to bridging mode, even though this would destroy the benefits of subnetting. There are cases where neither bridging mode nor NPTv6, nor DHCPv6 are feasible, e.g. if there are LLN subnets within the homenet which require remote access. In such cases a /64 assignment from an ISP will break the home network, and should therefore be avoided. Feel free to rewrite it. Mat ___ 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] regarding recursive DHCPv6-PD (and architecture document)
Oops, meant to reply to the list the first time... I see no reason not to do this... we'd have to have just about as much information to bridge successfully, and a few hundred routes is no big deal. Andrew On 8/11/2012, at 3:49 PM, Acee Lindem acee.lin...@ericsson.com wrote: Independent of the routing protocol, I don't think we want to inject a /128 advertisement for every device in the homenet into the homenet routing domain. Acee On Nov 8, 2012, at 3:21 PM, Andrew McGregor wrote: This whole thread is making me think that specifying that we use either babel (with attention to getting it documented properly) or one of the OSPFv4 MANET extensions, in the case where we have only a /64 and perhaps any time we find we have an 802.11s, ad-hoc or NBMA interface in play. That way we introduce /128 routes, and everything continues to work. Andrew On 8/11/2012, at 10:51 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 08/11/2012 15:09, Victor Kuarsingh wrote: even though this would destroy the benefits of subnetting. RCCI think it is arguable whether bridging is the least damaging solution. It fundamentally does not work with route-over multi-link subnets and would therefore require some extra L2 weirdness at a LLN border router. If ISPs are going to hobble us with /64s then I think you will find NPTv6 solutions appearing for the same reason NAT is used today. There are alternatives but, as noted in the architecture draft, these break SLAAC. So I think the onus is to push back on ISPs ofering /64s if we want to avoid any kludges./RCC Just to further some of the comments I made yesterday. I understand the we don¹t want a /64 to show up, but this may occur for reasons other then the primary intention of the ISP. Many things occur in a network - IP depletion/low avail blocks, errors, mis-configuration etc. No matter why it occurs, ignoring this case is likely not a good idea. I agree with earlier comments that this can be considered as a failure mode. It still needs to be considered for good engineering on how CPEs and homenet gear will behave. Exactly. It would be very bad for the end users to ignore this reality. On 08/11/2012 15:02, Sander Steffann wrote: So let's just say that giving a single /64 to the home is incompatible with homenet architecture, and we need more addresses. I'm fine with that. Yes please. I think some ISPs *need* to get a signal like this. Sure, but that does *not* excuse us from specifying how the end user gets service in such a situation. Brian ___ 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] regarding recursive DHCPv6-PD (and architecture document)
On Nov 8, 2012, at 4:40 PM, Andrew McGregor andrewm...@gmail.com wrote: I see no reason not to do this... we'd have to have just about as much information to bridge successfully, and a few hundred routes is no big deal. +1 I realize that I've been arguing for a different solution, but I agree that this is better. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
On 08/11/12 21:44, Ted Lemon wrote: On Nov 8, 2012, at 4:40 PM, Andrew McGregor andrewm...@gmail.com wrote: I see no reason not to do this... we'd have to have just about as much information to bridge successfully, and a few hundred routes is no big deal. +1 I realize that I've been arguing for a different solution, but I agree that this is better. For the stragglers, is this backwards compatible with existing devices? Will my Android phone, which expects to do DHCPv4 and SLAAC in one or more IPv6 /64s, connect unmodified to such a network? Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] regarding recursive DHCPv6-PD
Clarifying my remarks at the mic... Using PD in a home network isn't hard. Use a single delegating router; most obvious choice is the device that received the prefix from the external source. Every other router acts as a requesting router, and asks for a single /64 for each of its interfaces from the delegating router. draft-baker-homenet-prefix-assignment-01 has more details. Read it before you flame me. *Recursive* PD is, indeed, harder. Don't do it. - Ralph ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD
On Nov 7, 2012, at 10:51 AM, Ralph Droms rdroms.i...@gmail.com wrote: draft-baker-homenet-prefix-assignment-01 has more details. Read it before you flame me. Oh. Yay! I don't have to write a draft. Thanks, Ralph! (And thanks, Fred!) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD
On 7/11/2012, at 11:20 AM, Ted Lemon mel...@fugue.com wrote: On Nov 7, 2012, at 11:05 AM, Andrew McGregor andrewm...@gmail.com wrote: Recursive PD seems to inherently need some administrative input. BTW, our switch implementation can do either. I don't see what admin input it requires. The CPE edge router knows it's got a delegation, and signals to adjacent routers that it can act as a delegating router. Routers that get /64 delegations know that they can't act as delegating routers, and instead act as relays to the CPE edge router. This can all be done automatically. But that's single-delegating-router, not recursive. The problem with recursive is figuring out what prefix length a sub-delegating router is going to ask for from its upstream. For a single-delegating-router setup, you just ask for either a bunch of /64s or something that just contains enough of those to cover all your downstream interfaces. In a recursive situation, you don't know what you will need further downstream. Andrew ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD
On Nov 7, 2012, at 5:23 PM, Andrew McGregor andrewm...@gmail.com wrote: But that's single-delegating-router, not recursive. What is a recursive delegating router, and why do you want one? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD
On Nov 7, 2012, at 6:53 PM, Victor Kuarsingh victor.kuarsi...@gmail.com wrote: I am not sure I would agree that getting a /64 would inherently mean a router knows is an intermediate router. There are potential scenarios where an edge router may get a /64 and be the ISP edge router (not the best case scenario, but potential). I know this subtle point is somewhat outside the context of this thread, but just wanted to make the point. Such a router has no prefixes to delegate, so the distinction is immaterial. There can only be one non-translating router on this network. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD
On 2012-11-07 1:43 PM, Ted Lemon mel...@fugue.com wrote: On Nov 7, 2012, at 6:53 PM, Victor Kuarsingh victor.kuarsi...@gmail.com wrote: I am not sure I would agree that getting a /64 would inherently mean a router knows is an intermediate router. There are potential scenarios where an edge router may get a /64 and be the ISP edge router (not the best case scenario, but potential). I know this subtle point is somewhat outside the context of this thread, but just wanted to make the point. Such a router has no prefixes to delegate, so the distinction is immaterial. There can only be one non-translating router on this network. This is why I said it's a point outside the context of the main discussion (addressing within the homenet). My point was more around what assumptions may be made by routers which do in fact get a /64. Assuming that routers in the homenet will likely be using similar code (both those that show up on the edge and those which are intermediate ones), other router functions may be automated, including what mode of operation the router takes (edge vs. IR). An example may be security and/or filtering policy. It's the assumption related to those other instances that had me worried. Regards, Victor Kuarsingh ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD
On Nov 7, 2012, at 7:52 PM, Victor Kuarsingh victor.kuarsi...@gmail.com wrote: Assuming that routers in the homenet will likely be using similar code (both those that show up on the edge and those which are intermediate ones), other router functions may be automated, including what mode of operation the router takes (edge vs. IR). An example may be security and/or filtering policy. In the solution I'm talking about, you don't use similar code—you use the _same_ code. Realistically, CPE routers are all going to be essentially the same—there isn't going to be enough customer understanding to give rise to a market for second-hop homenet routers with different software. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD
On 7/11/2012, at 12:32 PM, Ted Lemon mel...@fugue.com wrote: On Nov 7, 2012, at 5:23 PM, Andrew McGregor andrewm...@gmail.com wrote: But that's single-delegating-router, not recursive. What is a recursive delegating router, and why do you want one? In general, I don't think you do. A recursive delegating router is one that will request a prefix, then load that as configuration into its own DHCP server and accept delegation requests from downstream, allocating out of that prefix. It's feasible, but awkward. You could instead, as I understood you were intending, run as a relay and forward downstream delegations instead. I still think the OSPF solution is better for homenet. Andrew ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
