Re: [homenet] support for HNCP in IPv6 CE routers
On 10/26/2017 11:39 AM, Gert Doering wrote: On Thu, Oct 26, 2017 at 11:32:44AM -0700, james woodyatt wrote: Accordingly, I strongly recommend that HOMENET dispense with the "My Friendly ISP" model with extreme prejudice, and adopt what I shall call the "HOMENET Castle Doctrine" as a matter of working group policy. I claim that this is a sure way to kill homenet from being ever deployed. I would counter that relying on ISPs to adopt a HOMENET standard is certain to fail. They have already demonstrated that they will block any revision to RFC 7084 that calls for adopting even HNCP, much less the rest of the HOMENET protocol stack. If you want to kill HOMENET, then make it a predicate that ISPs have to adopt it. That will ensure it goes nowhere at all. "Normal" People just don't buy a second router for their ISP link if they already have one, or a 3rd and 4th one if they happen to have two ISP links. So, what do we think a future home network for normal people is going to look like? I think "normal" people don't even want to buy the 1st router for their ISP link. What they want to do is have the ISP link go straight to their internet-connected device. Like a smart phone does. When you buy a new device, you buy a new ISP link for it. The protocols we are developing here in HOMENET are for the tiny minority of people who prefer to build their own home networks instead of just plumbing their ISP directly up to every device in their home. To facilitate that model, the HOMENET Castle Doctrine, I think we'll make its audience-- as well as ISPs-- happier, if we code our standards to the greatest common denominator of ISP linkage, then facilitate building HOMENET as a platform into which ISPs have zero visibility. --james ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] support for HNCP in IPv6 CE routers
On 10/26/2017 08:22 AM, Juliusz Chroboczek wrote: >On 10/24/2017 07:00 AM, Gert Doering wrote: >> I find the model of "there is a CPE, and behind that CPE, I connect another router to get homenet functionality" a bit unsatisfactory. I think there are two possible deployment models. 1. The « My Friendly ISP » model [...] 2. The « My Home, my Castle » model [...] I agree. Note that the « My Home, my Castle » model is more general, since it can implement the « My Friendly ISP » model by co-locating the EHR and the CPE. I don't think the opposite is true -- once you've leaked HNCP data to the ISP, there's no way to unleak it. Moreover, I don't believe there are any ISPs that are interested in the "My Friendly ISP" model at this time. And I would further contend that the word "friendly" is doing some rather Orwellian political work in that construction. Accordingly, I strongly recommend that HOMENET dispense with the "My Friendly ISP" model with extreme prejudice, and adopt what I shall call the "HOMENET Castle Doctrine" as a matter of working group policy. --james ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Firewall hole punching [was: About Ted's naming architecture...]
On Nov 22, 2016, at 14:39, Markus Stenberg <markus.stenb...@iki.fi> wrote: > > The recent IoT DDoS publicity is a good example; the devices that are the > Mirai botnet are devices that had/have open ports facing the internet. Not quite, c.f. <https://krebsonsecurity.com/2016/10/who-makes-the-iot-things-under-attack/ <https://krebsonsecurity.com/2016/10/who-makes-the-iot-things-under-attack/>> The vast majority of those devices were protected from receiving inbound flows over public Internet routes by the stateful filters of IPv4/NAT gateways. p1. Those ports would not have been open and facing the Internet except they were also configured to use UPnP IGD to punch a hole through their firewall to expose their unsecured services. p2. More importantly, they were also open and facing other compromised hosts on the same network, which were vulnerable not because they had open ports facing the Internet but because they were exposed to malware by legitimate requests to web servers at public Internet destinations. The calls [in both cases p1 and p2] were coming from inside the house. > It is all about reducing the attack surface. What attack surfaces were reduced? None of them were turned on at all. And why? Because, strangely, the industry in which we work engineers so many of the systems, which ordinary people are expected to use, in a way that makes them unusable unless all the security mechanisms that reduce the attack surfaces are disabled or bypassed by default. It’s not about reducing attack surfaces. It’s about making systems that are safe for deployment in close proximity to humans. --james woodyatt <j...@google.com <mailto:j...@google.com>> ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Firewall hole punching [was: About Ted's naming architecture...]
On Nov 22, 2016, at 11:47, Juliusz Chroboczek <j...@irif.fr> wrote: > > Assuming you want to allow hole punching, PCP makes sense. It only makes sense if the distinguished hole punched by the recommendations in Section 3.2.4 IPsec and Internet Key Exchange (IKE) [RFC 6092] are insufficient or unsuitable for the given application. > Whether you want to allow hole punching in the first place is a separate > discussion. A separate, closely related discussion is whether hole punching should continue to be “opt-in” or if it should be changed to be “opt-out” (assuming it’s even possible to make such a change at this late date, but the roll-out of HOMENET systems might bring an opportunity, should we choose to take it). I mean, it’s really quite revealing in Section 3.6 in "IPv6 Home Networking Architecture Principles" [RFC7368], which includes a long disquisition about the architecture expressly not taking any opinion on the “opt-in” or “opt-out” question, that the whole discussion gets reduced down to this fairly ambiguous sentence in Section 5.1 of “Home Networking Control Protocol” [RFC7788] to this rather unambiguous positive recommendation for filtering: >> Accessing internal resources from external interfaces is restricted, i.e., >> the use of Recommended Simple Security Capabilities in Customer Premises >> Equipments (CPEs) [RFC6092] is RECOMMENDED. On Nov 22, 2016, at 08:28, Michael Thomas <m...@mtcc.com> wrote: > > Right. Since Homenet is predicated on ipv6, we should never bake in > expectations of doglegging that have their justifications in v4/nat. […] I think we can safely observe that the expectation for passive listeners on unmanaged home networks to be protected by IPv6 Simple Security from receiving inbound flows from arbitrary hosts on the public Internet is not merely due to the legacy of IPv4/NAT. During the long and heated debate over RFC 4864 and the even longer and more heated debate over RFC 6092, I would say that the IETF community really did come to the consensus that eliminating the need for NAT to provide address amplification does not entail eliminating the need for simple security at the borders of unmanaged networks. That’s pretty clear in RFC 4864, and we had the opportunity to revisit in RFC 6092, and we did not. This argument that passive listener protection on unmanaged networks is an obsolescence left over from IPv4/NAT just doesn’t work. We had plenty of opportunities to leave it behind with IPv6 and we quite deliberately kept it. We can’t claim we didn’t know what we were doing. > There are perfectly good reasons I don't want to hand over control to some > dogleg servers […] thankyouverymuch. And yet, we have the Internet as it has been constructed in the real world according to its deliberately planned architecture, in which most if not all passive listeners on unmanaged residential networks are expected to be protected directly by security packet filters from receiving inbound flows directly from arbitrary initiators over public routes. The architecture instead expressly calls for them to make outbound flows to some exterior service that facilitates their communications or proxies on their behalf at application layers. That’s your dog-leg. We have it because IETF experts are afraid of the chaos entailed by allowing the riffraff to do without it too easily. Maybe the IETF community will revisit this architecture in the next version of the Internet Protocol, but with IPv6 I have to say the matter seems well and truly decided at this point. In the meantime, with the Internet we have, it doesn’t make sense to me why we should spend our time specifying protocols for registering names of services in the global domain name system unless we have a realistic usage scenario that shows how they will be reachable directly by arbitrary public hosts. I just don’t see how there is any such realistic scenario. Hence, I’m not sold that adopting this draft is a good idea. --james woodyatt <j...@google.com> ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] About Ted's naming architecture presentation and document
On Nov 21, 2016, at 15:11, Ted Lemon <mel...@fugue.com> wrote: > > Part of the goal of providing a naming infrastructure for the homenet > is precisely to avoid what you are describing, James. While it's > true that consumer IoT manufacturers do seem to be using that model > now, it's a broken model, and work is underway to obsolete it in the > open source world. Of course, that _does not_ mean that IoT devices > will be publishing their services in the public DNS, but the dogleg > model has many problems, not the least of which is that devices that > use it and control power consumption are a significant risk for > utilities. This goes to the heart of my criticism of the Homenet Naming Architecture draft. If there is anything in any of the Homenet working group documents or pending drafts that contradicts the recommendations of RFC 6092 that amount in practice to a prohibition against passive listeners in the home network from being reachable by arbitrary exterior hosts, then I’m not seeing it. Could you provide me with a pointer to the relevant passage in the drafts? Without that, I can’t see how there’s really a strong case for doing any of this naming architecture work. --james woodyatt <j...@google.com <mailto:j...@google.com>> ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] About Ted's naming architecture presentation and document
Hi Mike, Yeah, you have to dog-leg through a provider that you don’t trust. Because the providers you don’t trust are the only things that home automation device manufacturers are assured by the actual existing Internet will be reachable from arbitrarily located remote mobile handsets. Home automation controllers and similar servers on home networks will not generally be reachable from arbitrarily located remote mobile handsets without some kind of standard solution to the problem described in section 3.4, Passive Listeners of RFC 6092, which is widely deployed now in most residential IPv6 gateways. Note also that REC-49 of that document is also widely ignored in most implementations, certainly enough implementations that it cannot serve as a dependable mechanism. It’s also important that REC-48 has mostly gone without further attention since, and that certainly adds additional complications. Look on the bright side! Consider the possibilities that open before you when there is a 3rd-party provider that everyone can trust! > On Nov 21, 2016, at 11:46, Michael Thomas <m...@mtcc.com> wrote: > > You mean i have to dogleg through a provider who i don't trust? For whom I'm > the product? yuck. > > Mike > > On 11/21/2016 11:34 AM, james woodyatt wrote: >> On Nov 16, 2016, at 17:31, Michael Richardson < >> <mailto:mcr+i...@sandelman.ca>mcr+i...@sandelman.ca >> <mailto:mcr+i...@sandelman.ca>> wrote: >>> >>> But, do you agree that publishing your home lighting controller to the DNS >>> is >>> how you manage to control your lights from your phone when you are out of >>> wifi distance, as you roam to 3G. (I switch to 3G when I get to the front of >>> my rather modest driveway, as the AP is in the back of the basement)? >> >> If anybody is currently shipping, or has announced plans to ship, any kind >> of home automation device that does this, please speak up on the mailing >> list. I’d like to calibrate my perhaps mistaken apprehension that nobody >> would seriously consider doing this. Everyone I know in this field plans to >> do this by providing a single public rendezvous point with high availability >> servers that communicate in turn to home automation controllers acting as >> private clients. --james woodyatt <j...@google.com <mailto:j...@google.com>> ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] question: equal-cost multipath?
On Aug 26, 2015, at 01:07, Dave Taht dave.t...@gmail.com wrote: Another example of that problem is that it would be nice to have a standard for fetching what is my uplink/downlink rate from isps. upnp has some support for propagating this info, but it is underused and rarely configured properly. When I’ve seriously tried pulling hard on that rope in the past, the horrible ugliness at the other end was pretty nauseating. There usually isn’t a nice “uplink/downlink rate” number that retail providers can advertise. In a DOCSIS network, for example, the CMTS is typically not the narrowest queue in the path to/from the default free zone, physical layer asymmetry means that upward and downward limits are located in different positions, and the limits tend to be dynamic and sufficiently variable that using them for configuring AQM parameters in the subscriber gateway isn’t recommended. —james___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP and connected interfaces
On Aug 18, 2015, at 10:45, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Section 6.1 says: A node MUST be able to detect whether two of its local internal interfaces are connected, e.g., by detecting an identical remote interface being part of the Common Links of both local interfaces. Seems like this could be improved by rephrasing it to the effect that a node with multiple interfaces on the same common link MUST NOT advertise inconsistent information among them. That's too weak -- it also needs to take care to perform prefix assignment only once (although it will probably want to perform address assignment on both interfaces, especially if they're in ad-hoc mode), to run only one instance of RA and DHCPv4, etc. I'd really like to see it spelled out. Doesn’t section 6.3.1 already spell that out? Set of Shared Links: […] When multiple interfaces are detected as belonging to the same Common Link, prefix assignment is disabled on all of these interfaces except one. —james ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP and connected interfaces
On Aug 18, 2015, at 06:38, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Section 6.1 says: A node MUST be able to detect whether two of its local internal interfaces are connected, e.g., by detecting an identical remote interface being part of the Common Links of both local interfaces. What should the node do if it detects that two interfaces are on the same link? (Disable HNCP on one interface? Speak HNCP on both interfaces but disable prefix assignment? Something even more exciting?) Seems like this could be improved by rephrasing it to the effect that a node with multiple interfaces on the same common link MUST NOT advertise inconsistent information among them. —james ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [ieee-ietf-coord] Multicast on 802.11
On Aug 12, 2015, at 21:35, Henning Rogge hro...@gmail.com wrote: On Wed, Aug 12, 2015 at 10:13 PM, Joe Touch to...@isi.edu wrote: DAD is also needed to detect duplicates due to host misconfiguration, such as when a cloned MAC is added to the same network or when addresses are duplicated by other means (e.g., DHCPv6 misconfiguration). I couldn't confirm, but isn't this also not a local decision? I.e., if DAD fails you might end up with a duplicate address even when you set your IP addresses based on the burned-in MAC because others could select the same address randomly (I didn't see how that was avoided by the self-assignment algorithm). If you have a duplicate MAC then DAD will not safe you... you cannot communicate anyways because of a layer-2 problem. Yes, and DAD also has logic that limits the damage on the entire network when hosts join with duplicate L2 addresses, c.f. section 5.4.5 of RFC 4862. If the address is a link-local address formed from an interface identifier based on the hardware address, which is supposed to be uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP operation on the interface SHOULD be disabled. It’s worth noting that the presence of network sleep proxies can make this recommendation problematic. It would be better to disable the whole interface only when the actual L2 address is discovered to be duplicated, not just the link-local IPv6 address w/ embedded EUI-64 IID, which would allow DAD failures with sleep proxies on link-local addresses to be treated like a DAD failure with a sleep proxy on any other address. Alas, earwax. —james ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Multicast in 802.11 [was: Despair]
On Aug 6, 2015, at 17:42, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: I wasn't aware of the treatment of multicast packets as less than best effort in wireless transmission. That is not exactly intuitive, given that radio is inherently broadcast. Yes, that's counter-intuitive, but actually quite natural. 802.11 uses two different MAC sublayers: for unicast, it uses ARQ (typically 8-persistent) and varies the PHY rate (depending on e.g. pre-ARQ packet loss), while for multicast, it uses no ARQ and a fixed PHY rate. The effect is that unicast uses a higher data rate and virtually zero packet loss, while multicast uses a low data rate and suffers from significant packet loss (20% - 40% is not unusual for full-size frames, and I've seen 80% on a link that was quite usable, post-ARQ, for reading mail over IMAP). This is good enough for IPv6 (both ND and RA use little throughput and deal gracefully with reasonable packet loss), but makes multicast useless for some other applications. An additional complication with 802.11 is that various physical encodings use spacial beam forming for unicast and that’s not possible with multicast. It’s the main reason that transmission bit rates for unicast can be so much higher than for multicast— perhaps surprisingly so for people only accustomed to wired physical networking scenarios. It also has murky effects on coexistence between overlapping service sets, which are extremely common in high-density residential environments. —james ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On Aug 10, 2015, at 10:28, Fred Baker (fred) f...@cisco.com wrote: If every router is responsible to announce prefixes from ISP-Alice and ISP-Bob on every LAN, then Spanky has a distinct probability that, to get a packet to ISP-Alice, it will send it to ISP-Bob, who will then have to redirect it to ISP-Alice. If on that LAN, Alice advertises the ISp-Alice prefix and Bob advertises the ISP-Bob prefix, and Spanky presents the packet to the router that advertised its source prefix, Spanky will invariably present such a packet to Alice. To send a packet through ISP-Alice, it suffices for Spanky to send to any default router on its link that has a source-specific route for ISP-Alice through Alice, which HNCP seems to be capable of insuring that Bob will have if it’s smart enough to be advertising in its RA messages a prefix assigned from one of Alice’s delegations. Admittedly, this might not be optimal— a direct path from Spanky through Alice to ISP-Alice might perform better, as the section on Residual Issues in the draft notes— but there isn’t any obvious way currently defined to signal to hosts that a particular default router should be preferred over others for packets sourced from addresses corresponding to a Prefix Information Option. It may be tempting to think that conformance with RFC 6724 could help in the case where routers are coordinating to advertise only the assigned prefixes for which they are currently the best default router, but I suspect that it isn’t so simple and serious complications involving topology reconfiguration and RA timeouts can arise. I think that’s a general problem not specific to HOMENET, and 6MAN should decide what to think about I-D.baker-6man-multi-homed-host accordingly. —james___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] WG note taker and jabber scribe
On Jul 20, 2015, at 16:17, Ray Bellis r...@bellis.me.uk wrote: The Chairs would like to ask for advance volunteers for our session Wednesday afternoon to take notes of the meeting and relay comments from the jabber room. I volunteer to relay comments from the Jabber room. Someone else should take minutes. —james ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] shncpd and Router Advertisements, comments on hncp-06
On Jul 13, 2015, at 04:28, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Last night, shncpd learned to send RAs. It was a lot of fun. Bravissimo! —james ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Selecting a routing protocol for HOMENET
On Thu, Mar 26, 2015 at 3:58 PM, Lorenzo Colitti lore...@google.com wrote: On Thu, Mar 26, 2015 at 1:20 PM, Terry Manderson terry.mander...@icann.org wrote: So the the decision will not be made only on the work needed. Specifying the timeline means the design team must also consider the resources at hand, or reasonably available, to reach an acceptable, full, standardized solution. Can we make that explicit in the charter? Given how much time has already been spent here, I feel we must avoid a situation where the design team chooses a protocol, but then nobody is willing to implement it. So, I would like to see the charter say that the design team must confirm, before choosing the protocol, that there are volunteers to provide an implementation that meets the necessary resource constraints to be included in a home router. To my mind, if the perfect routing protocol were to descend from heaven, but did not have volunteers lined up to implement it in an appropriate time, the design team should reject it. Do we agree on that? I agree with this to a point, but I think the design team should be directed to do more than just identify volunteers who are committed to providing an implementation that meets the resource constraints of a typical home router device. I also think it should be directed to require that A) some implementation of the chosen protocol must be made available in source to the community under RAND licensing terms, and B) the volunteers must be committed to presenting in Prague a demonstration of that code running on typical hardware. Shorter james: just as it would be a failure if we pick a routing protocol that we can't standardize, it would also be a failure if we pick one that can't be demonstrated in running code. I hope this isn't a controversial statement. -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, Feb 27, 2015 at 2:28 PM, Dave Taht dave.t...@gmail.com wrote: [...] The next version of cerowrt will do translation from the external IPv6 address range to a static internal one (or ones, in the case of multiple egress gateways), and lacking a standard for such will use fcxx/8 addressing. I will make it be an option for people to turn off, but I've had it with being renumbered. And so it begins. I am sure this will break stuff, and I don't know what all it will do, and I intend to find out. I'd prefer that we simply consider CeroWRT with this change to be fundamentally broken, and begin by keeping track of the things that still work with it, rather than what it breaks. Until some far off day where we have stable name to ipv6 address mapping, and vice versa, it is otherwise impossible to have useful ipv6 based services inside the home or small business. Doesn't seem impossible to me. Too difficult? I could agree with that, but I would have to say it's the ubiquitous RFC 6092 filters that are going to kill that idea before the frequent renumbering does. Seriously, people: we could give up on the IPv6 servers on home and small business networks thing any day now, and I don't think we would lose much steam. Given that those filters are everywhere and turned on by default in most cases, it's only just a little bit worse if home gateways are using NPTv6 too. It's not like you could use working address referral if you wanted. (p.s. I'm aware of at least one other serious proposal to use NPTv6 in a shipping home gateway. It would be easier to argue against it if those RFC 6092 filters weren't installed everywhere.) -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-00.txt
Home gateways are typically not recursive resolvers. They're usually just translators for non-recursive DNS query/responses. Some have forwarding servers. There might be some that are recursive resolvers, but there are lot of good reasons not to put one there, starting with the fact that some service providers have a nasty habit of running split horizon at their authoritative resolving servers, and you lose all their lovely additional differentiating wonderfulness if you bypass their fancy special star-bellied nameservers and go straight to the root yourself. On Mon, Nov 17, 2014 at 9:20 PM, Michael Richardson mcr+i...@sandelman.ca wrote: Andrew Sullivan a...@anvilwalrusden.com wrote: Under DNSSEC, either the CPE has to be in the NS RRset (because otherwise it would fail validation; but this exposes an NS on the CPE to the world), or else it's not. I guess the idea is to answer authoritatively without being in the NS RRset? Some resilience mechanisms will treat that as a ijacking attempt, but I suppose if validation passes they shouldn't. The CPE is also often the recursive resolvers for the home, so I don't see the issue. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Next Steps for Routing Protocol
Dave, At Nest, we have different OS platforms we use depending on the constraints of the hardware. For things like the Nest Learning Thermostat, where there is a graphics subsystem and such, we use a $POSIX variant commonly found in larger embedded systems. It has not much flash and even less memory. We cut a lot of things out to make everything we need to fit, and we feel significant volatile and non-volatile memory pressure on this platform. For things like the Nest Protect, which are much smaller, we use a library-oriented $RTOS variant. The current Nest Protect device, for example, executes code from 512 kB of flash, using 64 kB of RAM. It has a very lightweight IPv6 stack, over which we have implemented all our communications protocols and our application logic. We are under truly extraordinary memory pressures on this platform, of the sort that I believe only somebody with experience working in the C64 demoware scene can fully appreciate. (Seriously, you can't even. Don't try.) I'm hoping future evolutions both in these product lines might have incrementally more resources, in which it may be possible to demand space for Comms Engineering to insert HNCP, when it's finally deployable. Assuming HNCP can be made to work. Lot of ifs. However, whatever happens, we eventually will need something that does what HNCP does, and I like HNCP itself better than I like the idea of rolling something proprietary. Does that help explain matters? On Sat, Nov 15, 2014 at 8:46 AM, Dave Taht dave.t...@gmail.com wrote: On Sat, Nov 15, 2014 at 7:55 AM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: This included technical discussion around a partially unanticipated I have always felt that we needed to have something that could route packets as best as possible based on conditions (and in particular transport configuration information) across many disparate link layers - homeplug, MoCa, 802.11, 802.11ad, 802.14, 6lowpan, VPNs, and sharks with lasers. ( https://twitter.com/RalfMuehlen/status/533414954167070720/photo/1 ). While full compliance with rfc2549 is not required, wires as we knew them are going the way of the dodo, and already have, in most homes and small businesses. requirement for HNCP to support a stub network with a gateway that doesn't have sufficient resources to run a routing protocol. Could someone describe what sort of resources these gateways (nest, I assume) actually have? - What OS they run, how much ram and flash is on them, is there virtual memory, etc? Are there devices in this category that can be hacked on? I am reminded of the dnssec debate put to rest by merely producing a proof of concept on an ancient cpe... I mean, babel, for example, is like, 61k, on mips with the sole dependency on libc. Other daemons, like pimd are in the same size category. Mark, Could you please spell out the requirements for a stub-only implementation? Do you expect the stub router to hold the full routing table, or just two routes (connected network and default route)? Is there interest in a stub-only implementation of Babel? Should it be a standalone daemon, or should it be integrated in the HNCP daemon? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Let's make in-home ULA presence a MUST !?
On Wed, Oct 22, 2014 at 12:19 AM, Markus Stenberg markus.stenb...@iki.fi wrote: My assertion: Given HNCP generated one spans whole administrative domain, _and_ should not have routing anywhere outside it, it’s uniqueness does not _matter_. Wait. Where did this and should not be routable anywhere outside recommendation come from? And if it's only a recommendation and not a requirement, then it still matters, right? I don't see that we can meaningfully make it a requirement, and I would advise against attempting to make it a recommendation. I don't believe such a recommendation will be followed. -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Let's make in-home ULA presence a MUST !?
On Wed, Oct 22, 2014 at 11:04 AM, Michael Richardson mcr+i...@sandelman.ca wrote: James Woodyatt j...@nestlabs.com wrote: My assertion: Given HNCP generated one spans whole administrative domain, _and_ should not have routing anywhere outside it, it’s uniqueness does not _matter_. Wait. Where did this and should not be routable anywhere outside recommendation come from? And if it's only a recommendation and not a requirement, then it still matters, right? I don't see that we can meaningfully make it a requirement, and I would advise against attempting to make it a recommendation. I don't believe such a recommendation will be followed. I won't mince words, recommendation/requirement/potato/etc.. I think it's a very strong SHOULD, the only reason for someone to do otherwise would by explicit geek-administator action. Manually configuring a VPN for example. It's not saying that ULA can never be routed by consenting adults, it's saying that the Homenet ULA SHOULD never be routed outside that homenet. Where it comes from; from the architecture document, I hope. I'm pretty sure we said that somewhere, but I'll have to go search for the specific statement. [...] You won't find it. It isn't actually there. There is some text that maybe you were thinking says it, but it doesn't, and the people who will be implementing this stuff will never look in the architecture document anyway, so it's moot. p1. I won't mince words either: the HOMENET architecture document is full of wrong on this topic. In particular, section 3.6.6 https://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.6.6. ULAs as a hint of connection origin makes the unwarranted assumption that subscriber home gateways are the only routers bordering the home network. They may often be the only *default* routers, but there can be— and absolutely definitely will be in the vast majority of cases— overlay networks that route ULA prefixes to, from and most likely *between* home networks over tunnels. We can't tell people not to do that. If there is a routing protocol in a HOMENET, then it will be done, and it ought to work right. p2. These overlay networks will not be for geeks only and they will not require advanced manual network configuration skills. If this issue isn't handled right in HOMENET, then we can expect each of those overlay networks (there will almost certainly be more than one in many homes) to use delegated ULA prefixes instead of the HNCP locally-generated prefixes if necessary, but that just goes to show that the locally-generated prefixes are likely to be crippled compared to the ones from overlay networks, which will actually be generated and delegated properly to keep them from colliding on network joins and splits. What's the point of having a HNCP locally-generated ULA prefix if it doesn't actually have the statistical properties of collision avoidance that ULA prefixes were designed in the first place to have? -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Let's make in-home ULA presence a MUST !?
On Wed, Oct 22, 2014 at 12:51 PM, Ted Lemon mel...@fugue.com wrote: On Oct 22, 2014, at 2:46 PM, James Woodyatt j...@nestlabs.com wrote: They may often be the only *default* routers, but there can be— and absolutely definitely will be in the vast majority of cases— overlay networks that route ULA prefixes to, from and most likely *between* home networks over tunnels. We can't tell people not to do that. If there is a routing protocol in a HOMENET, then it will be done, and it ought to work right. In the case where ULAs are being routed like this, wouldn't that ULA be the responsibility of whatever homenet federation protocol is being used? I don't disagree that this is a valid use case, but I don't think it would rely on the homenet ULA. My point is that it doesn't need to be done that way unless HOMENET forces that design choice. I see a way to work around the potential problem here— by eating the expense of requiring the overlay routers between HOMENET site boundaries to exchange the full raft of valid /64 routes in all the currently valid locally-generated ULA prefixes instead of exchanging just the aggregated /48 ULA prefixes. I suppose that can be made to mostly work in the majority of cases at the cost of memory and efficiency for interior routers. Don't grow your home networks too big, however, or the interior routers in your house— or in your friend's house— might fall over when the overlay connects. -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Let's make in-home ULA presence a MUST !?
On Mon, Oct 20, 2014 at 12:34 PM, Ted Lemon mel...@fugue.com wrote: On Oct 20, 2014, at 2:00 PM, James Woodyatt j...@nestlabs.com wrote: Okay... except it seems you're admitting that my scenario where a simple reconfiguration of a network topology, e.g. one caused by an intermittent RF interference on an unlicensed band of the radio spectrum, would result in a fully regular and normalized generation of a ULA prefix that would subsequently be deprecated on network rejoin and subsequently deprecated again. This could happen several times per hour, right? No, if it's done right the network would have to be partitioned for on the order of a week or two before the new ULA would be generated. Did you respond to my previous criticism of this idea? If so, then I missed it. It's not a good idea to commission a new standalone network with the same ULA as a previously commissioned network, because it destroys the main property of ULA prefixes that makes them useful: the statistical unlikelihood of merge collisions in the global address realm. The reason I think it's beneficial is that it reduces to the minimum the number of instances where a long-lived connection will have to be broken because of a renumbering event. I don't think we can reduce that number to zero, but I think we can make it a lot less likely than it would be if we renumber every time the upstream link goes away. Sounds to me like a benefit of very dubious value at best. It's a fact that applications cannot depend on the network never encountering a renumbering event. That's the whole reason addresses have valid and preferred lifetimes in the first place. Applications that use long-lived IPv6 connections cannot escape the problem that interface addresses may expire at any time. If they're not coded to recover from such events, then it's their logic error, not ours. I see no reason to work very hard to provide applications with a class of global scope interface addresses that IETF documents encourage developers to assume will never reach vltime=0 except when that assumption is mysteriously invalid anyway because reasons. If there is a good reason for it, which I'm missing, then I'm happy to consider it. -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Let's make in-home ULA presence a MUST !?
On Mon, Oct 20, 2014 at 1:32 PM, Ted Lemon mel...@fugue.com wrote: Yes, I read your explanation, and the solution I proposed takes it into account. Please stop arguing to win and actually read what I wrote. I did read what you wrote, and I do not agree that you are taking into account my concerns. Nevertheless, I shall stop arguing my case, and I will accept that I've lost it. -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Let's make in-home ULA presence a MUST !?
On Fri, Oct 17, 2014 at 12:54 PM, Ted Lemon mel...@fugue.com wrote: On Oct 17, 2014, at 2:49 PM, James Woodyatt j...@nestlabs.com wrote: As I recall, the proposals in your response were less than concrete and didn't solve the problems. In particular, I remain curious about how to expire the locally generated ULA prefixes that accumulate over repeated network joins and splits. I remember explaining how those events could be rather more frequent than people might be assuming, and that's where the discourse seemed to stop. If you don't burn a ULA prefix every time you split and rejoin, then I don't see why there would be any kind of significant growth in prefixes. That's why I suggested the algorithm that I suggested. I explained why you must generate a new ULA prefix every time you commission a new network. It's true that not every split entails commissioning a new network, especially when the AAA service for the previously commissioned network is still available on both sides of the split, but that isn't always true, and besides, human user behavior must still be accounted. Whenever you have AAA service, you are attempting to automate what humans think about who is and who isn't allowed to do what. Sometimes people change their plans. Sometimes people don't plan at all. Sometimes people make plans and don't tell anyone, much less the silicon beasties in their house. Sometimes they make plans without even recognizing it. Routers have to operate mostly in the dark when a split happens. They may not be able to determine whether they are still expected to be members of the previously commissioned network or if they have been repurposed into a new network until well after they have been operating split for some time, and perhaps joined with other networks in the meantime. After a split, they may need to operate in a mode that allows them to commission a new standalone network at any time when they are split from a previously commissioned network. In any case, we have defined a way for locally generated ULA prefixes distributed in persistent storage of HOMENET interior routers to accumulate without limit when independently commissioned networks join. Offering the view that sensible people don't commission new networks very frequently is not a solution to the problem. It's a way of implying the problem isn't relevant to your interests. The problem may not be relevant to your interests, but it is to mine. -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Let's make in-home ULA presence a MUST !?
On Tue, Oct 14, 2014 at 3:28 PM, Ted Lemon mel...@fugue.com wrote: On Oct 14, 2014, at 5:14 PM, James Woodyatt j...@nestlabs.com wrote: But there is a problem with only deprecating prefixes without expiring them. If they never expire, then they accumulate without limit within existing networks as they join with newly commissioned networks over the course of their lifetimes. Ah, sorry, I didn't mean to say that we deprecate them but don't ever get rid of them. I think once a deprecated ULA has expired, it should be gc'd. If the homenet is partitioned, the two options are for the partitions to continue using one ULA and try to keep prefixes stable, in anticipation of the partition being healed later, or for both partitions to switch to new ULAs, or for one homenet router to own the ULA and get to keep it for use in whichever partition it winds up in, while the other partition has to choose a new ULA. Personally I think keeping the ULA stable across partitions is preferable, but I'm not sure it's possible to do it without the risk of flash renumbering. So what's the problem? My language above ensures that home network hosts always have at least one gracefully renumbered IPv6 address routable throughout the entire network. If we need a further guarantee that hosts always have an *invariant* address— which is an objective you've said above that you think we don't actually have— only then are we faced with the problem of prefix accumulation through network joins, which is a problem I'm not sure we know how to solve effectively. My proposal avoids that trouble. I understood your language to be trying to get rid of all ULAs if any GUAs are present. Did I misunderstand? Mr. Lemon, this is the only message in this thread where I can find you saying anything about the expiration of locally generate ULA prefixes. p1. It looks like you agree that locally generate ULA prefixes should be allowed to expire. What I don't see is any conceptual outline for deciding, in a distributed methodology, which prefixes to renew and which to release when their valid lifetime expires. Without seeing that, I can't agree that you've proposed anything that solves the problem I keep yammering about, much less offered a better solution than the one I proposed earlier in the thread. p2. I also remain confused about the reasoning behind calling for a persistent locally-generated ULA prefix. In a previous message you said that it's okay for locally-generated ULA prefixes to expire, because there is no need for hosts on home networks to have any guarantee that at least one of its interface addresses is invariant over time, just that at least one of their addresses is never flash renumbered when a delegated prefix changes. As Lorenzo has demonstrated earlier today, this quality of never being flash-renumbered is easily met by delegated ULA and ordinary GUA prefixes. Returning to my question: why do we always need a locally-generated ULA prefix? If it's to provide a time-invariant locally routable address to hosts, then locally generated ULA prefixes cannot ever be permitted to expire for any reason. If they are ever allowed to expire, then they don't provide the time-invariant property. However, if we don't actually need the time-invariant property, then what does a locally-generated ULA prefix do for us whenever one or more delegated prefixes is also present? It's not clear to me they are anything but absolutely redundant and unnecessary in that situation. -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Let's make in-home ULA presence a MUST !?
On Wed, Oct 15, 2014 at 4:14 AM, Sander Steffann san...@steffann.nl wrote: [I wrote:] Consider a hypothetical router that has the regular automatic default behavior of commissioning a new standalone network while discovering any existing networks that it already possesses the credentials to join. Now consider what happens when devices of this category are continually losing and regaining their connectivity with the rest of the wireless network in the home. Let's imagine this happens many times per hour. How many days does it take before all your constrained-resource hosts have no space left in their route tables for all the deprecated but still valid ULA prefixes? Does it have to be a *new* standalone network (ULA prefix)? The router could just generate a ULA prefix once and reuse it whenever it needs to, right? Generating a new prefix on every connect/disconnect would indeed cause a mess... No, the router can't do that. Consider that ULA prefixes may be advertised through tunnels to one or more exterior private routing domains that communicate with multiple home networks simultaneously. Because the locally generated ULA prefix is copied from the commissioning router to all the other routers in the home network, a router must therefore generate a new ULA prefix at every network commissioning to preserve the property that ULA prefixes are statistically unlikely to collide. Otherwise, every time a single device is used to commission a new network with the same ULA prefix, that prefix will collide with existing previously commissioned networks at the exterior domain gateway. -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Let's make in-home ULA presence a MUST !?
On Wed, Oct 15, 2014 at 1:01 PM, Michael Thomas m...@mtcc.com wrote: [...] I really don't want to have my network break connectivity because I happened to switch to my neighbor's wifi and I was using a ULA when I could have kept connectivity with a GUA. Except REC-49 in RFC 6092 does not recommend transparency as the default operating mode of residential gateway firewalls. And very few in actual deployments are transparent by default. So this can't be expected to work even with GUA instead of ULA. -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Let's make in-home ULA presence a MUST !?
On Tue, Oct 14, 2014 at 1:24 AM, Markus Stenberg markus.stenb...@iki.fi wrote: From my point of view, it should be SHOULD _always_ generate ULA (so that privacy oriented things in a home have a sane default without need for trusting firewalling), and MUST generate if no GUA around. I don't understand [and I'm not sure I like seeing it] this clause about privacy oriented things and trusting firewalling in the context of RFC 4193 unique local addressing. I suspect there is some conflation with RFC 1918 privacy addressing happening there [which is why I am frowning]. On the topic of the original question, if I were to editorialize here, then I would want to see something like this: A) An autonomously generated ULA prefix SHOULD be advertised when no other delegated prefix is valid. B) Whenever there is any valid delegated prefix, advertisements for an existing autonomously generated ULA prefix MUST be deprecated, i.e. updated with preferred lifetime of zero. C) A deprecated autonomously generated ULA prefix MUST be withdrawn when it expires, i.e. its valid time reaches zero. D) Whenever there is no longer any valid delegated prefix, advertisements for a previously deprecated autonomously generated ULA prefix MUST be updated with non-zero preferred lifetime. The idea here is to make sure IPv6 applications can generally rely on home network interior routers to forward traffic among the multiple links in the home, regardless of whether any first-mile Internet services are provisioned, configured and operational, i.e. there shall always be at least one preferred global scope network prefix, and there shall be an autonomously generated local prefix available as a last resort whenever there are no valid delegated prefixes. -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Let's make in-home ULA presence a MUST !?
On Tue, Oct 14, 2014 at 12:31 PM, Ted Lemon mel...@fugue.com wrote: [...] This is where I am just completely puzzled. We talked about this previously. I thought the idea was that the homenet ULA should converge: that there should only be one, ultimately [...] This is exactly what I'm trying to surface in my earlier comments about I-D.ietf-homenet-prefix-delegation. That idea needs clarification if we're going to interoperate with network layers like Thread which have their ULA prefix that it would be good to advertise in HOMENET domains as a delegated prefix. If the idea is to minimize the need for a HOMENET autonomously generated ULA prefix, then it should only be advertised when not other ULA prefix is available and it should be deprecated and allowed to expire when it isn't needed. If on the other hand, we do not see a need to limit the number of ULA prefixes advertised into the HOMENET domain, then a persistent one should be generated when the network is commissioned by its first leader, and it should always be advertised thereafter whether a first-mile service is operational or not, and regardless whether the initiating leader leaves the network. (There is a problem with the latter case, which is that some legacy host operating systems are still broken in an environment like that, and it would be helpful to mitigate such brokenness. The former case doesn't have that problem. There is also the exception that arises when two networks with different ULA prefixes are joined— now you have one network, with two ULA prefixes, neither of which can ever be allowed to expire.) On Tue, Oct 14, 2014 at 12:44 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: At a stroke this would destroy the main advantage of ULAs - namely, invariant addresses for internal traffic. IPv6 assumes multiple simultaneous addresses; there is no reason whatever to artificially prevent use of ULAs alongside GUAs. p1. I don't want to prevent the use of ULAs alongside GUAs. Indeed, I need for this to be preserved, and I'm very concerned about requirement language that would seem to interfere with that. p2. While I'm in agreement there is a benefit in a guarantee for hosts on home networks that they will always have valid addresses in the interior routing domain, I'm not sure I can agree that the main reason to use a ULA prefix is to encourage the supposition that a HOMENET generated ULA is more stable and persistent than any GUA assigned by a first-mile service. I suppose if the working group has already argued that to death, and concluded that stable persistent addressing solves a problem that real people are actually facing, then it's not worth rehashing that discussion. If we're going to go with HOMENET always generating a ULA prefix at network commissioning time and persisting for the life of the network, then I'm going to need to understand better how we're handling network joins and splits. -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Let's make in-home ULA presence a MUST !?
On Tue, Oct 14, 2014 at 2:35 PM, Ted Lemon mel...@fugue.com wrote: When we talked about this previously, I think the idea was that when two networks with two sets of ULA prefixes merge, you deprecate one of them. [...] Naturally, you deprecate one of them, but my concern is that they never expire if the objective is for a ULA prefix to be invariant. So how many times can a network join with others before it runs out of space for deprecated and redundant but unexpired and invariant ULA prefixes? -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Let's make in-home ULA presence a MUST !?
On Tue, Oct 14, 2014 at 2:49 PM, Ted Lemon mel...@fugue.com wrote: I don't think the objective is for the ULA prefix to be invariant. It's for the availability of a ULA prefix to be dependable, and for flash renumbering to be avoided whenever possible. So there's no problem with deprecating a ULA when you have two, and no need for the ULA to remain stable over long periods of time. But there is a problem with only deprecating prefixes without expiring them. If they never expire, then they accumulate without limit within existing networks as they join with newly commissioned networks over the course of their lifetimes. The reason to want there to always be a ULA is that if you use a GUA as a ULA, the life cycle of your home network numbering is out of your control, and in the hands of whoever gave you the GUA. That's the only thing I think the ULA prefix has to do on a homenet: provide you with dependable, graceful homenet-local numbering. So what's the problem? My language above ensures that home network hosts always have at least one gracefully renumbered IPv6 address routable throughout the entire network. If we need a further guarantee that hosts always have an *invariant* address— which is an objective you've said above that you think we don't actually have— only then are we faced with the problem of prefix accumulation through network joins, which is a problem I'm not sure we know how to solve effectively. My proposal avoids that trouble. -- To answer a previous question: I would say the reason I thought it worth expressly zeroing the preferred lifetime on the locally generate ULA prefix when another prefix is advertised is to expedite the transition to preferring any delegated ULA prefix over the locally generated one. Admittedly this is perhaps not worth the effort, and I won't argue further for it. -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D.ietf-homenet-prefix-assignment (RFC 4193 conformance)
On Thu, Oct 9, 2014 at 2:04 AM, Pierre Pfister pierre.pfis...@darou.fr wrote: What do you think of the following proposal ? It allows any router to generate a ULA (it adds more complexity because collisions must be avoided, even though the Backoff was necessary at boot anyway). As this is a Standards Track requirements draft, I hope to be excused if I'm seeming to be overly pedantic, but this revision still leaves me concerned that we are setting requirements that do not admit Thread networks into HOMENET routing domains. Here is the excerpt that I find most troubling: ULA prefixes may be provided by DHCPv6-PD or static configuration, as specified in Section 4.3, in which case they are not considered as spontaneously generated and MUST NOT be withdrawn if another ULA delegated prefix is observed. My problem is that Thread networks autonomously number themselves with a ULA /64 prefix, i.e. a ULA /48 prefix with a well-known 16-bit subnet identifier. This happens when the first element in a disconnected network commissions itself. Thread networks will keep this /64 prefix as more elements are commissioned with network credentials to join the mesh. In the highly likely event that one or more elements capable of acting as Thread border routers to the HOMENET domain later join the mesh, then each of them would naturally want to advertise into the HOMENET domain this autonomously generated ULA /64 prefix. The language in this proposed revision still seems to admit only ULA delegated prefixes obtained by DHCPv6-PD and by *static* configuration, but neither of those are applicable in the case of Thread networks. I think my concern might be ameliorated by drawing a distinction in the requirements between a single distinguished Home ULA Prefix and any number of other Exterior ULA Prefix delegations. The former prefix is autonomously generated by the HOMENET router in the Leader role, whereas the latter are delegated by exterior numbering authorities outside the HOMENET domain, and they are just like any other globally scoped IPv6 network prefix. Would it be helpful if I tried to write up a proposed set of edits for this? -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D.ietf-homenet-prefix-assignment (RFC 4193 conformance)
On Thu, Oct 9, 2014 at 12:26 PM, Pierre Pfister pierre.pfis...@darou.fr wrote: But I’m going to change it and making it more clear that authorities can provide their own prefixes. Even ULAs. Thanks! I'm very pleased to see this agreement. -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D.ietf-homenet-prefix-assignment
On Tue, Oct 7, 2014 at 5:32 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 08/10/2014 12:14, James Woodyatt wrote: The requirements keywords in this section make for a pretty serious interop clash with Thread networks http://threadgroup.org/, which generate their own ULA prefix based on a method defined by its current conventions. I sincerely hope that method conforms to RFC4193. Yes, it does. -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D.ietf-homenet-prefix-assignment
On Wed, Oct 8, 2014 at 12:30 AM, Markus Stenberg markus.stenb...@iki.fi wrote: On 8.10.2014, at 2.14, James Woodyatt j...@nestlabs.com wrote: The requirements keywords in this section make for a pretty serious interop clash with Thread networks http://threadgroup.org/, which generate their own ULA prefix based on a method defined by its current conventions. I do not think it precludes use of ULAs otherwise, just prevents their spontaneous generation according to that particular 0-1 ULAs-in-a-network algorithm. That may be the intent, but if so then that wasn't clear to me in reading it. Just out of curiosity, have you experimented with actually providing ULAs and IPv4 connectivity only to normal hosts? We tried that experiment in late 2012 (Atlanta IETF 86) and the results based on variety of hosts IETF comers came to play with us at the time were somewhat mixed. Some hosts notably wanted to use the ULA instead of v4 (and in one case, even ULA over IPv6 GUA). That, combined with the fact that you more or less have to provide default route to have that ULA usable (thanks to MSR RA option being ignored by half the players out there currently), and you may have trouble. Experimented? We shipped already. Yes, we have some problems with hosts running a certain family of operating systems that don't process RFC 4191 MSR options. We reported the problem several years ago, but there are very few signs of anything in the works to help. My hope is that we will eventually see industry adoption of HOMENET, which will provide interior routing domains into which we may advertise our Thread networks via our border routers, providing interoperability with those hosts that don't accept MSR options in our RA messages. In the meantime, we must do something horrible, crude and proprietary where an elegant, standard solution would be, of course, so much more preferable. -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] automatic prefix management (OSPF or ISIS version)
On Feb 25, 2013, at 19:35 , Lorenzo Colitti lore...@google.com wrote: However, the moment you try to use more /64s internally than you have externally, stateless NPTv6 doesn't work any more, right? Correct. But remember: I *never* write NAT66 when what I mean is NPTv6. I really did mean NAT66 and not NPTv6. In this scenario, we would number HOMENET domains with 16 bits of ULA subnet identifier and 64 bits of interface identifier for hosts on each subnet. Then we would NAT66 the ULA /48 prefix into whatever addresses are in the pool of longer prefixes the service provider gives us because they won't give us a /48 at an acceptable price. We would not use NPTv6, as that doesn't work. We would then use the PCP protocol to control NAT66 mappings just the same as we do today with NAT44 mappings, but the good news is that PCP explicitly supports that form of IPv6/NAT so it's all good. Thank you PCP working group. Yes, this breaks referral in IPv6 even more than it's already broken, but I'm thinking service providers will be happy with that overall. If I were building an IPv6 home gateway to support routed home networks today, this is how I would feel compelled to do it. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] automatic prefix management (OSPF or ISIS version)
On Feb 23, 2013, at 14:24 , Fred Baker (fred) f...@cisco.com wrote: One: the v6ops result reflects the operational result in the ARIN community: operators there would like to be able to allocate /56 prefixes to smaller customers and /48s to larger ones. If you want castigate someone, castigate them. I'm unable to participate in ARIN or other RIR discussions, otherwise they would have heard a bellyful from me about it. I'd castigate *them* here too, but that would be off topic. Two: If randomization within the home is the issue, I'm not sure the difference between a /48 and a /56 is all that significant. The point I wished to make is that we don't have a reasonable expectation that the size of a HOMENET subnet identifier will ever be constant over time and across renumbering events, much less across transfers between providers. We're not even confident that a HOMENET will even be offered *any* space for a subnet identifier. As a result, it means that Automatic Prefix Management here is basically unable to do it statelessly, i.e. by randomly generating subnet numbers from an identifier space of conventional size and testing for collision before using them. Any HOMENET autoprefix system will depend on the proper configuration of a central subnet identifier registry integrated or tightly coupled with the border gateway. When new link routers arrive, they have to ask the central registry for the next available subnet identifier and take out a lease on it, just like an IPv4 host that has to maintain a lease to use its interface addresses with DHCP. When link routers leave, they have to release their lease or the network must wait for it to timeout. And what happens when a HOMENET has four link routers in it, and the ISP renumbers the delegated prefix from a /60 to a /63? Obviously, something in the network has to kick two of the routers out of the HOMENET, but which two? Does the subscriber even get to choose? Basically, we've given up on stateless router autoconfiguration in HOMENET, and we're forced into a stateful solution. There are no good choices here, and the worst case outcome is that we will force the widespread adoption of NAT66 at HOMNET borders, precisely because it may turn out that subscribers want stable subnet identifiers, and more of them than their service providers are willing to provide at reasonable price. This all happened before, and we're not showing any signs of making sure it doesn't happen again. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] automatic prefix management (OSPF or ISIS version)
On Feb 25, 2013, at 16:28 , Lorenzo Colitti lore...@google.com wrote: On Tue, Feb 26, 2013 at 4:21 AM, james woodyatt j...@apple.com wrote: As a result, it means that Automatic Prefix Management here is basically unable to do it statelessly, i.e. by randomly generating subnet numbers from an identifier space of conventional size and testing for collision before using them. Why do you say this? Assuming the ISP(s) providing service to the home assign enough space to number all the links (e.g., /60, /56, or /48), then what's the problem? p1. I don't believe it's reasonable to assume that service providers will always provide a short enough prefix to number all the links in a subscriber's network, or that those that currently do will continue to do so into the foreseeable future, or that they will even give notice prior to reducing the space delegated to a subscriber. p2. In a decent sized subscriber network, with several subnets in place, a /56 delegation means a small but significant changes that a randomly selected subnet identifier will collide with an existing one, whenever a router joins the network. With a /60, the odds climb quite a bit, and in some networks it will be 15/16. (Do not make the mistake of assuming that router joins and leaves will be infrequent events. Plan for them happening several times per second, or you will be sorry later.) p3. All this pain can be traded away for the reasonably well-understood pain of NAT66 and a single ULA prefix with a constant 16-bit subnet identifier space, where collisions will be rare and stateless prefix autoconfiguration will settle quickly basically every time. I personally don't think that's a good trade, but if routed home networks are ever to become the normal setup, then I'm very skeptical that my opinion will turn out to be the majority one. I think if we want to avoid the temptation of subscribers to deploy NAT66 to preserve the stability of their 16-bit subnet identifier space in the face of service providers enhancing their choices with a variety of plans with varying policies for prefix delegation, then we have to do it with a stateful subnet manager in the network, near the border gateways. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] automatic prefix management (OSPF or ISIS version)
On Feb 22, 2013, at 06:16 , Michael Richardson mcr+i...@sandelman.ca wrote: If the ISP with the longest prefix is alive first, then the routers pick subnet-id parts that fit into that. If that ISP has provided enough subnets, then even when another ISP comes along, the xx23 part might remain stable for a long time. This problem is precisely why I campaigned bitterly and vigorously against the adoption and V6OPS and later the publication of RFC 6177. When there was still a consensus that subscribers should always get a /48 prefix, it was reasonable to expect that a randomly chosen 16-bit subnet identifier would be unlikely to collide with another subnet in most automatically numbered routing domains. We were also in a position to expect that when a subscriber adds a new prefix from the same or a different provider, that all the subnet identifiers in use on one prefix could be mapped 1:1 into the new prefix. Now we have RFC 6177, which explodes all of that, for basically no sensible reason that I can see, and we are all the poorer for it. Well done, V6OPS, well done. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On Nov 15, 2012, at 04:26 , Ted Lemon mel...@fugue.com wrote: On Nov 14, 2012, at 10:41 PM, james woodyatt j...@apple.com wrote: However notionally easy this problem is to address, I imagine that practical matters, at some point, must rise to the top of the pile of points to consider. Those hosts are broken. They can't work in a multi-homed environment. Those hosts are not broken. They work fine in single-homed edge networks, which are ubiquitous. The deployment of multiple heterogenous default routers with hosts that expect networks to be single-homed is what breaks the network. Also, rule 5.5 of RFC 6724 is inadequate. Hosts that implement it should work better than those that don't because new flows created after the primary default router becomes unreachable should automatically go to the next available default router, but existing flows will still be broken in the absence of the kind of coordination I described previously. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On Nov 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] I-D Action: draft-haddad-homenet-multihomed-00
On Oct 26, 2012, at 24:29 , Teco Boot t...@inf-net.nl wrote: Opinions? Seems like a straight-up job for IPsec, which is why RFC 6092 has section 3.2.4 IPsec and Internet Key Exchange (IKE). -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On Oct 23, 2012, at 01:29 , Ray Bellis ray.bel...@nominet.org.uk wrote: On 22 Oct 2012, at 19:57, james woodyatt j...@apple.com wrote: I would say that it MUST be deprecated by the arch document. The arch document is Informational and contains no RFC 2119 keywords. My email to the list was an individual exhortation, and it contained no RFC 2119 keywords. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On Oct 23, 2012, at 08:20 , Michael Thomas m...@mtcc.com wrote: On 10/22/2012 08:35 PM, Lorenzo Colitti wrote: Can you explain why this behaviour, combined with the prefer matching interface rule in RFC 3484, is not sufficient? If not, then there is no problem to solve here. Your ISP gives you 2001::: via SLAAC. Your employer gives you 2000::, but also has 2001:::. You connect to a server on 2001:::. Your 3484 v6 stack picks 2001: for the source address. Hilarity ensues: My IPv6 stack doesn't pick a 2001::... address. When the VPN client connects, it inserts a more-specific host route to 2001:::/z via the VPN pseudo-interface, so the IPv6 stack picks the interface address assigned by the VPN access concentrator as the source address for application flows to the 2001::/z network. Hilarity does not ensue. Happy faces on the security team. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On Oct 22, 2012, at 06:12 , Tim Chown t...@ecs.soton.ac.uk wrote: Therefore what seems to be on the table for homenet are: [...] d) NPT66 (RFC6296), which the homenet arch does not recommend, but see draft-bonica-v6-multihome-03. [...] Why is this option still on the table? Who is arguing for it? Can we strengthen HOMENET arch to deprecate NPT66 explicitly? -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
On Oct 22, 2012, at 11:28 , mike m...@mtcc.com wrote: I'd say that until we have source address selection that actually works and is widely deployed, that taking anything off the table is premature. Source address selection applies just as much on a homenet as anyplace else. Disagree. My opinion is that the potential for catastrophic damage to the utility of the Internet by the ubiquitous deployment of NPT66 in residential gateways poses too grave a risk for us to continue seriously entertaining it as a viable approach to any of the problems in our ambit. I would say that it MUST be deprecated by the arch document. For anyone arguing in favor of using NPT66 in residential gateways, I think it's fair to ask them for solutions to the problem statement in I-D.carpenter-referral-ps http://tools.ietf.org/html/draft-carpenter-referral-ps in support of that idea. Referral in IPv4 was badly broken by the introduction of NAT44, and the ubiquitous deployment of NPT66 in residential gateways would repeat the error with IPv6. I would say HOMENET should not be seriously considering that as an option. Is there any significant disagreement on that point? Are there people here who might be willing to stand up and argue that the referral problem is secondary to other objectives well served by deploying NPT66 in home network access routers? If so, then what are those objectives? I'm having a hard time understanding what they might be. Probably even moreso when you consider corporate VPN's. Actually, VPN is usually just a special case of MIF, i.e. individual hosts are multihomed, not the whole homenet. This is a much simpler situation to manage, and solutions for that space are already ubiquitous. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Unicast DNS within the Homenet?
On Sep 11, 2012, at 11:07 , Evan Hunt e...@isc.org wrote: This does raise a point, though: Dynamic DNS doesn't have an expiration mechanism. [...] My home zone is cluttered up with the names of a couple of dozen laptops and ipods belonging to neighbors and visitors over the past year. [...] I recommend reading section 5 of Understanding Apple's Back-to-My-Mac Service [RFC 6281], which gives a brief summary of how this problem is effectively and reliably managed in that system. There you will find references to the following truly under-loved technical specifications: http://tools.ietf.org/html/draft-sekar-dns-ul http://tools.ietf.org/html/draft-sekar-dns-llq Maybe HOMENET could push for these to be taken up as IETF work items? -- james woodyatt j...@apple.com member of technical staff, core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Unicast DNS within the Homenet?
On Sep 10, 2012, at 05:34 , Ray Bellis ray.bel...@nominet.org.uk wrote: An interesting question has come up during the Arch Doc team's discussions around naming and service discovery: What in-home services actually require Unicast DNS lookup? [*] Really? How has the architecture team managed to overlook the obvious problem that homenets with interior routing domains comprising multiple networks cannot use either mDNS or LLMNR, which are confined to link-local multicast scope, without requiring name service proxies? As Brian notes, you could try to resurrect SLP, but-- really? I don't see that happening. Name service proxies also sound like a major undertaking compared to ordinary unicast DNS. What an exciting distributed database scheme with which consider securing its integrity... I can't wait. Alternatively, you could try to extend mDNS and/or LLMNR to support a wider multicast scope, then require routed homenets to implement some kind of multicast routing protocol. That sounds like a big specification effort and I'm not sanguine about the chances for adoption there. Finally, we could punt on the homenet routing problem, and just use mDNS+DNS-SD exclusively-- I'm sure I can think of at least one major player in the home networking space that would be quite happy to see such an outcome turn out to be the status quo, but last I checked, this working group didn't like that idea very much. So, um-- I guess the answer to the Arch Doc team's question should be, NAME ALL THE THINGS IN DNS!! What am I missing? -- james woodyatt j...@apple.com member of technical staff, core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] naming, what's the problem?
On Aug 28, 2012, at 17:42 , Mark Andrews ma...@isc.org wrote: Repeat until you have the entire 128 bits for all registered nodes in the /48. You shouldn't expect to get the temporary addresses. Only the persistent ones, and some nodes-- particularly the ones that host only clients and no services-- should neither be listening at persistent addresses, nor advertising pointers to their persistent addresses in ip6.arpa. I'm not terribly exercised about the other kinds of nodes. The problem of globally reachable servers being findable by iterating the ip6.arpa reverse domain name system doesn't seem very pressing to me. Sounds like a feature not an error. --james ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Reverse DNS
everyone-- Before we get too far down the road dreaming up how to register names for hosts on home networks, I'd like to suggest gently that a related problem, i.e. how to register authoritative name services for the subdomains of ip6.arpa corresponding to prefixes delegated to home networks, is a lot more pressing. For your consideration, my personal home server currently resides at 2001:5a8:4:2290::102. Here's what dig -x currently returns for that IPv6 host address: $ dig -x 2001:5a8:4:2290::102 ; DiG 9.8.1-P1 -x 2001:5a8:4:2290::102 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 2427 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;2.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.2.2.4.0.0.0.8.a.5.0.1.0.0.2.ip6.arpa. IN PTR ;; ANSWER SECTION: 2.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.2.2.4.0.0.0.8.a.5.0.1.0.0.2.ip6.arpa. 86400 IN PTR grymling.conjury.org. ;; Query time: 371 msec ;; SERVER: 2620:149:5:f09::53#53(2620:149:5:f09::53) ;; WHEN: Mon Jul 30 11:43:57 2012 ;; MSG SIZE rcvd: 124 The steps I had to go through to be sure that such queries were answerable were not the steps I would want to defend in a feature usability review. I realize that solving this problem with a standard would involve more working groups than HOMENET, but clearly the effort needs to start here. Once we have a good idea how to solve this problem, then I think it will be easier to talk about forward DNS coherently. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reverse DNS
On Jul 30, 2012, at 13:28 , Ted Lemon mel...@fugue.com wrote: The work's already started in the dhc working group: http://tools.ietf.org/html/draft-lemon-dhc-dns-pd I'd be curious to hear your feedback on this draft. That's a good submission for the DHC group. I'm thinking I'd much more like to see a specific recommendation that HOMENET gateways implement a site-managed reverse tree, optionally augmented with a zero-configuration method for generating content explicitly managed by a knowledgeable home network administrator. For example, after I install a fresh HOMENET gateway in my new house, I expect the following things just to happen correctly without any forethought: 1. The integrated DNS content server should have authority for all of the ip6.arpa corresponding to the IPv6 prefixes delegated by its service provider; 2. The integrated DNS resolving server should answer [on the local network only] for the locally generated ULA prefixes required by RFC 6106. 3. Queries for PTR records in zones for which it's authoritative should always produce a synthesized answer if no explicitly configured records are stored in the content server. For examples, 3a. dig -x fd35:5a4b:92a9:fb::1 - fd35-5a4b-92a9-fb--1.local. 3b. dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc - 2001-5a8-4-2290-a95f-dd2e-3201-eafc.subscriber-3021134.example.net. 4. I should be able to override explicitly the domain automatically delegated by my service provider with my own registered FQDN if I want to do so, so that example 3b above becomes: 3b.(2). dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc - 2001-5a8-4-2290-a95f-dd2e-3201-eafc.conjury.org. 5. I should be able to override explicitly the automatically generated FQDN for any hosts on my network if I want to do so, so that examples 3a and 3b above become: 3b.(3). dig -x fd35:5a4b:92a9:fb::1 - zardoz.local. 3b.(4). dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc - zardoz.subscriber-3021134.example.net. 6. I should be able to do both. 3b.(5). dig -x fd35:5a4b:92a9:fb::1 - zardoz.home.conjury.org. 3b.(6). dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc - zardoz.conjury.org. Yes, I get that DNSOP people don't like to contemplate this problem. I don't want to debate about why I think they're wrong to defer it, but my thoughts aren't all that different from those of anyone else in the application/security community. Can we skip past the part when I enumerate them again? I guess I had hoped the HOMENET group would more easily find consensus around addressing this promptly, but that may have been wishful thinking. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] a modest proposal
On Jul 30, 2012, at 11:08 , Michael Thomas m...@mtcc.com wrote: If we believe that ipv6 is ready to go for mass deployment, why do we not pressure home router vendors to default to sending router advertisements with ULA addresses that, if necessary, get NAT'd at the border just like 192.168 space does today. I mean, nothing bad would happen, right? What does the conditional phrase if necessary mean in your mind? Under what circumstances do you imagine this would not be necessary for operational continuity? -- james woodyatt j...@apple.com member of technical staff, core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Name service design principles: a proposal
On Jun 29, 2012, at 13:57 , Michael Thomas m...@mtcc.com wrote: Can I use service discovery from across the Internet to get back to things in my home assuming that I have a registered domain? Last login: Fri Jun 29 14:52:05 on ttys000 zephyr ~ 501$ ssh -p 22 j...@zeece.303183.members.btmm.icloud.com. Last login: Fri Jun 29 14:55:24 2012 from fd3a:a6fe:48b6:8b35:c1aa:9b69:17ce:fb01 zeece ~ 501$ I could post pictures of what it looks like when I go to configure my Time Capsule at home remotely from my desk in Cupertino, but that would be a waste of valuable IETF remailer resources. Suffice to say it works like this: p1. Launch the AirPort Utility (which is used for configuring Time Capsule). p2. Click on Other Base Stations button in the upper right of the main window. p3. Choose James's Home Time Capsule from the pop-up menu. p4. A configuration window opens. Make changes. Click Save and the window closes. Step p2 above starts the browse for AirPort and Time Capsule configuration services in the list of domains my system is automatically configured to search, which includes my iCloud member domain, but it could include any other domains. The browse operation queries for PTR records containing names of SRV records, and it results in the list presented in the pop-up menu. Step p3 above starts the locate for the chosen Time Capsule service instance. The locate operation queries for SRV records, as well as the A and/or records corresponding to the hostname part of the service resources. Step p4 above starts parallel TCP connections to one or more of the destination addresses returned by the locate operation, in a sensible order and possibly in parallel, until one of them connects or they all fail. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I have a problem
On May 7, 2012, at 11:39 , Dan Wing dw...@cisco.com wrote: I don't know how to make one of these systems work without a rendezvous service, and it seems nobody else does, either -- all of them rely on some sort of rendezvous service that is separate from the service provided by the typical residential ISP. The rendezvous[*] service used by BTMM is the Domain Name System. There isn't anything particularly magical about BTMM that prevents dyndns.org or anyone else from implementing their own Wide-area Bonjour domain using DNS servers outside of Apple's control. Indeed, some folks do exactly that with their home networks using their own DNS servers. Check out http://www.dns-sd.org/ClientSetup.html for more details. Also, I too think this discussion is off topic for HOMENET. -- james woodyatt j...@apple.com member of technical staff, core os networking [*] c.f. http://www.appleinsider.com/articles/05/02/18/apple_to_rename_rendezvous_technology_bonjour.html ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Security goals
On Mar 14, 2012, at 08:16 , Michael Richardson m...@sandelman.ca wrote: whatever we set as the recommended default will be what is there for 99% of users, and therefore what anyone writing an application that has to live in the home is going to have to deal with. A point I have been trying to make for several years now is that we have already set a recommended default in many places for block all incoming connections at unmanaged Internet gateways. We probably had a chance to reverse course on this for IPv6 in the middle of the last decade, but not anymore. We now have a strategic direction we have been following for quite some time now, and we have too much invested in it to turn back. I think the credit for preserving the continuity of the IPv4/NAT experience with the transition to IPv6 should go to the IAB and the IESG. The HOMENET architecture should throw in the towel on E2E and go with RFC 6092 on by default at the border gateway. It should be silent about PCP until something can be done about its lack of explicit support for nested security domains. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Home DNS server for homenet
On Mar 6, 2012, at 07:15 , Michael Richardson m...@sandelman.ca wrote: Mark == Mark Andrews ma...@isc.org writes: Mark A significant percentage of home machines will roam and those Mark machines will need to be able to register their current Mark address in the DNS. I do this today when my Mac roams. TSIG Mark is unavoidable and cheap. UPDATE itself is relatively cheap. Are you asking for a link-local/mDNS-across-the-homenet leap-of-faith way to do key establishment so that TSIG can be initialized? The alternative is to delegate all that business to 3rd parties with big data centers in the proverbial cloud. Yes, that means that you're relying on Internet service to be constantly available to resolve service locations on your local home network, but it does seem to work reasonably well today. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing requirements
On Oct 24, 2011, at 10:22 PM, Lorenzo Colitti wrote: If a cell phone operator gives you a single /64, what do you propose to do? If a certain CableLabs MSO gives each of its several tens of millions of Internet users in North America only a single /64, what do we propose to do? -- james woodyatt j...@apple.com member of technical staff, core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing requirements
On Oct 24, 2011, at 1:24 AM, Ray Bellis wrote: Will those arguing for ND Proxy please stand up and be counted? I have long complained that certain WPAN physical layers should be prepared to attach to home networks, either by application layer gateways on bastion hosts, or by dedicated ND/RD proxy devices, rather than by demanding that every residential network deploy a standard zero configuration prefix delegation and routing protocol to interface to these peculiar WPAN networks. I know I'm in the minority on this. I don't think I can point to anyone who agrees with me. Still, I should be counted. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet strawman slides
On Oct 12, 2011, at 1:52 PM, Curtis Villamizar wrote: A router should not start handing out PD or even IPv4 NAT space until it gets and address from elsewhere. Some routers need to do this, i.e. home routers where service providers charge prohibitive rates for always-on Internet dial-tone and expect subscribers to connect on demand and disconnect after an appropriate idle time. For IPv4 today, these routers typically use PPPoE on the WAN and they often handle this by assigning RFC 1918 address to the LAN hosts and using DNS queries to signal PPPoE to establish the WAN link. For IPv6, I'm not sure what they should do, but I have some ideas. Basically, the router should advertise as a default router with a single ULA prefix and a DNS server at the router's ULA interface address with RFC 6106 and optionally RFC 3736. When the DNS query signals PPPoE to establish the WAN link, the DHCPv6 client will ask for a IA_PD and update the prefix advertised on the LAN accordingly. I'm not sure this model can be made to work with IPv6, but I wouldn't put it past the telcos to try. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [homegate] HOMENET working group proposal
On Aug 7, 2011, at 5:15 PM, Mark Andrews wrote: One think I haven't seen mentions w.r.t. firewalls is protecting the rest of the world from compromised home machines. While ISP's should be doing BCP 38 filtering, CPE devices should also be filtering outgoing traffic that is not from a valid prefix. [...] Then I would direct your attention to Recommendation #5 in RFC 6092, which informs the implementers of residential firewalls thusly: REC-5: Outbound packets MUST NOT be forwarded if the source address in their outer IPv6 header does not have a unicast prefix configured for use by globally reachable nodes on the interior network. Does that about cover it? -- james woodyatt j...@apple.com member of technical staff, core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [v6ops] default LAN routing protocol for IPv6 CE router
On Aug 3, 2011, at 21:03 , Robert Cragie wrote: L2 bridging is OK if you can do it but not everything looks like Ethernet frames. Not only that but if we have multi-link subnets using route-over, the router to host ratio goes up considerably. The problem space is then multi-link subnets then multi-subnet site/zone/homenets. L3 routing is the only way this is going to work in homenet. This is not strictly true. ND-proxy is an alternative. I've been told it's not a *viable* alternative--- for unspecified and possibly non-technical reasons-- but it is an alternative. I've got a big bucket of popcorn to munch while I watch this discussion play out, and I really don't have a strong opinion one way or another. My take, to the extent I have one, is that in comparison to L2-briding and ND-proxy, L3 routing on home networks will be a bag of hurt (to borrow a phrase from Le Grande Fromage), but if that's the direction from which rough consensus will emerge... well, okay then. Let's open up the bag. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
