Re: [homenet] Partitioned links [was: Stub networks]
In message 87sidddh3l.wl-...@pps.univ-paris-diderot.fr Juliusz Chroboczek writes: Another topic comes to mind. The topic is the partitioned bridged network. The first situation was informally described by R. Tomlinson as a network partitioning problem in which a particular host, H in network N, is reachable from one gateway attached to network N but not another, because network N has become partitioned into two or more pieces. [...] The third situation arises in connection with an advanced airborne packet radio application. It first emerged in conversations with Major L. Druffel of the DARPA/IPT office. In this case, long-range packet radios (200-300 miles) are installed in aircraft and on the ground at selected sites. The ground sites may or may not have connectivity with each other (e.g., through a wire network and gateways). While aircraft are aloft, they communicate with each other and the ground via packet radios. If we treat the ground packet radio networks as a single net (for internet addressing purposes) and include the airborne packet radios as a part of that net, then this creates the partitioned network problem which was raised by R. Tomlinson. -- Vint Cerf, IEN 110, 1979 While I happen to be an advocate of advertising a /128 on the host, as you suggest, I'd like to point out that HNCP might finally solve this 40 year-old issue. Draft-ietf-homenet-prefix-assignment is not very clear on this issue, but I think that it implies that the algorithm is re-run when a link is partitioned -- which causes renumbering and causes two prefixes to be assigned to the now partitioned link. Pierre, is that correct? Does it need clarifying in your draft? Interestingly enough, the memo cited above describes the issue of multihomed hosts losing TCP connections when one of the networks goes down -- an issue that MP-TCP is finally solving 40 years later. -- Juliusz Juliusz, If HNCP renumbers on a partition, then existing TCP connections would drop. Numbering the loopback avoids this. Also there is the solution used in the 1990s by ISPs which you trimmed from my email, but requires installing host routes. Also consider what might happen with an intermittent link between switches if the solution is to renumber on a subnet partition (which should occur, but for the interface addresses only, if not using link local). My preferred solution is: 1) always number the loopback except for legacy hosts, 2) use link local interface addresses on a point to point interface including Ethernet with two hosts except for legacy hosts, 3) number any broadcast interface using HNCP (or since this is my preference, extend OSPF - no flames please). Thanks for the historic reference. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]
Brian, Good points. See inline. Plus a new point below. In message 54f8ae20.5030...@gmail.com Brian E Carpenter writes: Hi, 8. Support for Stub Networks and Stub Routers ... IS-IS supports stub-networks as defined above simply by advertising the prefix associated with a link, but not the link itself. This is sometimes referred to as a passive link. Further an IS-IS router has the ability to set a bit (the overload bit) to indicate that it should not be used for any transit traffic, and that it will only be considered a destination for the prefixes it has advertised, i.e., it is a stub router as defined above. In both ISIS and OSPF is an neighbor adjacency is formed with another router, the adjacency to a network pseudonode is advertised. If no other router is found, then no pseudonode is formed and just the prefix is announced as a stub. ... As all distance vector protocols, Babel supports fairly arbitrary route filtering. Designating a stub network is done with two statements in the current implementation's filtering language. In a homenet, there must be no manual config. In both cases, how does this work automatically? How does IS-IS know not to advertise the link and set the overload bit, and how does Babel know to include those filtering rules? Or more generally, how does a stub router know that it's a stub router, when there is no human to tell it so? Regards Brian Another topic comes to mind. The topic is the partitioned bridged network. It looks like this. +---+ +---+ | Rtr#1 |- Link#1 -| Rtr#2 | +---+ +---+ | | ... other links... other links | | +---+ +---+ | Rtr#3 |- Link#2 -| Rtr#4 | +---+ +---+ | I#3 | I#4 | | +---+ +---+ | Sw#1 |---/ broken /---| Sw#2 | +---+ same subnet numbering +---+ | | | | +--/--- ... ---/--++--/--- ... ---/--+ | | | | | | | | +---+ more more +---+ | host1 | subnet subnet| host2 | +---+ drops drops +---+ legend: Rtr# = a router; I# = an interface example: I#3= 192.0.2.1; I#4= 192.0.2.2; subnet= 192.0.2/24 In IPv6, make that 2001:db8:fff0::/64 In this example all of the host and router interfaces are up. This is not a misconfiguration. Some bridging was used and a link between bridges is down. In ISIS and OSPF both the interface on the router and the prefix is advertised. In ISIS and OSPF sometimes just the prefix is advertised to save on /32 (/128) prefixes floating about, but that affects some reachability to router interface addresses (but never to the loopback if numbered, which is why they are always numbered in ISP networks). That makes two ways to reach the subnet, and therefore to reach host1 and host2 when bridging is working. In ISIS and OSPF when this link between bridges goes down, the routers are always reachable through their loopback addresses. If pinging the interface is desireable, mostly just so as not to confuse operators doing manual ping, the router interfaces can be advertised and they are always reachable. The hosts, in this example, host1 and host2, but potentially quite a few more, are only reachable from parts of the network. Any router closer in the topology to Rtr#3 including Rtr#3 can't reach host2. Any router closer in the topology to Rtr#4 including Rtr#4 can't reach host1. One solution for an ISP where host1 and host2 are important (for example NMS data collection nodes), is to run ISIS or OSPF on the host and make them stub routers if they are multihomed (the old way before stub router support was set cost to a very high number). This was done in the gated days (gated is an older routing daemon) but is doable with Bird or Quagga. This yielded a slow switchover, but a reliable one. Mostly reliable. Some routers didn't install the interface addresses in the FIB (falsely assuming that the subnet address was plenty) but they were beat up about it, so maybe that problem is gone. BTW- If there were other routers still connected to Rtr#3 or Rtr#4, then a DR and BDR was elected and the network pseudonode with save prefix was advertised from more than one router. This is why ISPs don't particularly care for switched
Re: [homenet] L2 link status [was: More about marginal links]
In message CAGnRvuqcwFjE6NZ_tOnQEBN8RG8wUFeSsQSqsETh=acpw_v...@mail.gmail.com Henning Rogge writes: Sorry, too much working on the implementation side of NHDP/OLSRv2 in the last years... should have thought a bit more about the reply before sending it. Yes, you are correct that RFC6130 does not contain the description of the link metric... it only contains a rough EWMA based link quality hysteresis that switches on and of links. I don't even think the algorithm defined in the RFC is really useful (but its easy to plug in a different one because the Link Quality calculation and decision is just local). I was thinking about the Link Metric NHDP extension defined in RFC7181 (which can easily be used without using the OLSRv2 routing), which is based on Incoming/Outgoing Link Metric values. (in my implementation I put the whole Link Metric and MPR code into NHDP to make them usable without OLSRv2) Henning Rogge The basis for the metric in RFC 7181 is out of scope. So what did you use? Also I'm not sure what you meant by the MPR code. Did you leave in the LINK_METRIC TLV and leave out the rest of RFC 7181? So my point still stands that there is nothing like LQM is anything over WiFi (more correctly 802.11). Curtis On Tue, Mar 3, 2015 at 12:28 AM, Curtis Villamizar cur...@ipv6.occnc.com wrote: Henning, You cut the following off the top of your reply. The Neighborhood Discovery Protocol (RFC 6130) has a similar mechanism... each node collects local link quality information and then shares them from time to time with all neighbors, which means everyone knows about both directions of a link. Henning Rogge RFC 6130 uses probes (hello message success rate). Cutting this off makes a big difference. See below. In message CAGnRvup-F4_A1-sHkh3EWRgrX=iuthbdmjzz+xk_g+7bm+e...@mail.gmail.com Henning Rogge writes: On Sun, Mar 1, 2015 at 11:14 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: RFC 6130 uses probes (hello message success rate). No, it does not... at least not for calculating the link metric. The discussion was the quality measurement. The quality measurement uses hello message success rate. See section 14 in RFC 6130. The discussion was not link metrics. You chopped the prior discussion when quoting the one sentence above. Below I describe the why RFC 6130 Link Quality is nothing like LQM. For example: If an AP sends 100 packets a second to a neightbor and 5 drop it would be better to send one LQM packet and know that loss is 5% rather than have to send 100 hello packets in addition to the 100 data packets to reliably know that loss is 5%. (In MPLS it could be a billion packets between LM packets). LQM does not rely on a count of probe packet success. Please reread what I sent earlier or read about PPP LQM or MPLS-TP LM OAM. Please compare RFC 6130 section 14.2 (Basic Principles of Link Quality) Link quality and Link metric are two different kind of things for NHDP/OLSRv2. Link quality is used for a hysteresis mechanism that can make a link symmetric/asymmetric. Link metric (as defined in RFC 7181) is used for path selection. with RFC 1989 and RFC 6375. In RFC 6375 look at Section 2.2 (Packet Loss Measurement) and Section 3.1 (Loss Measurement Message Format). RFC 6130 has no comparable mechanism. RFC6130 (NHDP) and RFC 7181 (OLSRv2) define the incoming link METRIC calculation as an external process. It can be anything, as long as it gives you a dimensional link cost in the right range. I admit the splitup between RFC6130 and RFC7181 is a bit confusing... Henning Rogge I know the difference between link quality and link metric. You just jumped from ND to OLSRv2 for MANET. RFC 7181 does not preclude using a LQM-like mechanism, but neither RFC 6130 or RFC 7181 define such a mechanism. The discussion was regarding doing something like LQM and three messages ago you stated that RFC 6130 already had something like LQM. Neither RFC 6130 or RFC 7181 define a mechanism anything like LQM. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
In message CAGnRvuq+kq+djqPvKHDXBdDkbfjt=gnj0owqvc241vllwxb...@mail.gmail.com Henning Rogge writes: On Tue, Mar 3, 2015 at 8:12 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: The basis for the metric in RFC 7181 is out of scope. So what did you use? This: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-04 It seems like with this draft, packet with RFC 5444 (Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format) sequence numbers are counted and absent any of those, only HELLO packets are counted. If all packets had RFC 5444 sequence numbers this would have the same effect as LQM. Unfortunately this requires the host to use RFC 5444 encapsulation over WiFi. Unfortunately LQM requires both side to play. On the bright side, a host would only need to copy counters into a packet to allow the AP to gather information. I am still using the multicast loss (plus the raw link speed) to judge the links, but I have done some early experiments with integrating the L2 frame statistics too. Not sure it works that well for wifi without a lot of probing, much more than you need for getting an useful link speed). It would be nice to write down somewhere (preferably and internet-draft for WG purposes) exactly what you end up with once you've made good progress on this. Also I'm not sure what you meant by the MPR code. Did you leave in the LINK_METRIC TLV and leave out the rest of RFC 7181? Multipoint Relays. Its a method to reduce the flooding overhead in a wireless mesh network. Its defined in RFC 7181, but its a modification of NHDP so I put it into my NHDP implementation. So my point still stands that there is nothing like LQM is anything over WiFi (more correctly 802.11). With an Atheros card I get both transmitted frames, retransmitted frames and (completely) lost frames on the sender side of a link... its just that these values are not that useful when most of your wireless links are not transporting traffic. Henning Rogge Its great that you are working on wireless mesh networks. IMHO the typical homenet environment is Ethernet plus WiFi in AP mode, not mesh. Its good to have things that work well for mesh. Right now it would be really good to have solutions for the problem of lots of AP in a confined area. In some cases, such as appartment buildings with lots of consumer run AP, the issue is keeping the density of AP from congesting airwaves. In other cases (such as IETF, or an enterprise with lots of APs) hosts will be roaming among APs and that should be smoother than it is now. Unfortunately I don't think that is fixable with zero host changes. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-mrw-homenet-rtg-comparison-01
In message 87ioejy629.wl-...@pps.univ-paris-diderot.fr Juliusz Chroboczek writes: I'll do my best to see whether there's anything I can use at this exteremely late date without annoying my co-authors too much. Sorry for that. By the way, the current version of the draft is on https://github.com/choppsv1/hn-rtg-cmp/ I think it meets many of your changes, please see whether you can provide changes against that version. -- Juliusz Juliusz, I just did a diff using svn. You only took three very minor changes. So a reply regarding the rest of it would be nice. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-mrw-homenet-rtg-comparison-01
In message 7i1tl7jdjs.wl-...@pps.univ-paris-diderot.fr Juliusz Chroboczek writes: Dear Curtis, I've just read through your mail carefully. While you make some good points, I think that, unless a champion appears, OSPF will not be reconsidered in time for Dallas. Additionally, many of your changes merely change the stress of the document, and I'd rather not be making stylistic changes right now. I've made the following changes according to your wishes: - changed the stress from homenets are unadministered to add mostly; - inserted your note about dedicated homenet protocols. Please let me know if there are other points (not related to OSPF) that you feel strongly about. -- Juliusz Its hard to argue with that installed base of 4 cerowrt users. :-) Please reread. Some of the comments were about how OSPF and ISIS work. For example there is no such thing as an ISIS LSP. It is a Link State Protocol Data Unit (LSPDU) and the fragments are called LSPDU fragments. There are also comments about convergence time and the common use of BFD with ISIS where tight coupling with L2 fault detection is not available. No provider has used the 10sec/30sec timers in about two decades and generally regard the 1sec/3sec setting too slow, so use BFD. If OSPF is rejected on the basis that it is not yet linked into openwrt that is a lame reason to reject a candidate IMHO, but if that is the reason it should be in the document. If that changes, then OSPF should be reconsidered. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
In message c8e13842-f1d9-4768-86a7-3b2ea1e56...@chopps.org Christian Hopps writes: On Mar 2, 2015, at 8:00 AM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. I see that you've been speaking with Abrahamsson. Please let me give you some background. It's not just Mikael that has this opinion, he's just the more active email participant. If true should we be calling this out more explicitly in the document? I seem to recall that I already mentioned that I find your tendency to bring out controversial arguments just before a deadline somewhat offputting. There was nothing nefarious here. I just thought of a question and raised it. I think we should be open to doing that any time free of attack. Thanks, Chris. I agree with Chris. WGs are allowed to change their decisions particularly in early stages when there is no significant ***deployment***. Even then WGs can take a new direction but need to include backward compatibility or at least have a solid plan for (hopefully painless) transition. For example, MPLS started with RSVP-TE and CRLDP and years later dropped CRLDP due to lack of deployment. CIDR obsoleted EGP, BGP1-3, RIP1, and lots of other protocols, but there was a good reason and a clear transition plan. The way IETF has normally done things is to allow multiple developments to exist if they have support and then drop only those that are not being deployed or prove to be less desirable. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
In message 7615609f-512e-42aa-a2e7-4dbb31f1a...@chopps.org Christian Hopps writes: Hi homenet-wg, One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. If true should we be calling this out more explicitly in the document? Thanks, Chris. Chris, Yes. I agree. And OSPF could do the same, without dragging CLNP in with it. Maybe ISIS-WG should consider an ISIS-over-IP draft? Oh wait - non-routability of CLNP is a security feature - so don't forget to mention that in the security section. You might need providers to use filters at borders and GTSM as they do for OSPF. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
In message 54f4d7bb.3050...@gmail.com Brian E Carpenter writes: Hi Toerless, On 03/03/2015 10:23, Toerless Eckert wrote: Would any of those rfc explain to me what the problems with renumbering in a homenet are that Fave tried to avoid by doing NAT ? And how those issues can not be mitigated by better workarounds than NAT ? http://tools.ietf.org/html/rfc7010 is the gap analysis, but for enterprise networks. I think what Dave is actually saying is that complex home networks of the future (which is where he already lives) inherit many of these problems, with difference that renumbering will be imposed by the ISP, so the element of choice and planning that an enterprise network has is missing. Somebody needs to work on RFC7010-for-homenet, I guess. Its zero conf. It just happens. Seriously. OTOH, if there are devices with configured addresses then it would be nice if the person running the network knew what they were, where they were located, and how to access them to make changes. (Curtis is right, of course: if a network is designed and managed with renumbering treated as an expected event, life would be better.) Brian Its really not a matter of treated renumbering as an expected event. Good network planning results in knowing how you've allocated subnets, which servers were given fixed addresses, and what DHCP pools exist. Good network management involves also checking to see that hosts you see for fixed addresses you don't know about including those within the pools (no DHCP lease in the logs but something there at the top range of the pool). Its also nice to know when a rogue host or DHCP server shows up and have the means to isolate its physical location. For example, a box that went nuts and started spewing packets. That type of good planning and good management leads to a simple and straightforward renumbering as long as there is a grace period for the transition. If maintenance of configs is automated, then the renumber can be done in record time. Curtis On Sun, Mar 01, 2015 at 02:24:08PM +1300, Brian E Carpenter wrote: Admittedly 6renum was targetted at enterprise networks, partly because of the observation that homenets renumber anyway after every power cut. But we have spent a lot of cycles on this issue. http://tools.ietf.org/html/rfc4192 http://tools.ietf.org/html/rfc5887 http://tools.ietf.org/html/rfc6866 http://tools.ietf.org/html/rfc6879 http://tools.ietf.org/html/rfc7010 and maybe it's time to revive https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines Brian On 01/03/2015 12:40, Curtis Villamizar wrote: In message caa93jw4tumfm_lvzkrx7ark2z+hwtw5jboenpvfejut4l9t...@mail.gmail.com Dave Taht writes: On Fri, Feb 27, 2015 at 2:00 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: In message 54ee258e.8060...@gmail.com Brian E Carpenter writes: On 26/02/2015 05:14, Mikael Abrahamsson wrote: On Wed, 25 Feb 2015, Ray Hunter wrote: That way the devices can roam at L3, without all of the nasty side effects of re-establishing TPC sessions, or updating dynamic naming services, or having to run an L2 overlay network everywhere, or having to support protocols that require a specialised partner in crime on the server side (mTCP, shim6 et al). It's my firm belief that we need to rid clients of IP address dependence for its sessions. Asking clients to participate in HNCP only addresses the problem where HNCP is used. Fixing this for real would reap benefits for devices moving between any kind of network, multiple providers, mobile/fixed etc. Violent agreement. This is not a homenet problem; it's an IP problem. In fact, it's exactly why IP addresses are considered harmful in some quarters. Trying to fix it just for homenet seems pointless. http://www.sigcomm.org/ccr/papers/2014/April/000.008 Brian Brian, Seriously - your paper may be overstating the problem. At least if we discount IPv4 and in doing so eliminate NAT we solve a lot of problems that never should have existed in the first place. If we carry NAT over to IPV6, then shame on us. I am sorry, I no longer share this opinion. The pains of renumbering someones entire home network every time the ISP feels like it, given the enormous number of devices I have encountered that don't handle it well, are just too much to bear. I renumbered 140.222/16 into 147.225/16 in the mid 1990s (T3-NSFNET to ANSNET as part of the NSFNET decommissioning). Not by myself of course, but there were only a few of us on this. It wasn't all that bad and we had about 2,000 things to renumber in hundreds of locations, many of them not manned. Shell scripts and ksh (kerberized rsh, not the Korn shell) made it simpler. The worst was Cisco routers and various old DSU/CSU and other commercial stuff since you had to use expect scripts on their CLI
Re: [homenet] routing protocol comparison document and hncp
In message 87twy3wjtr.wl-...@pps.univ-paris-diderot.fr Juliusz Chroboczek writes: I got my hands on ISO 10589 today and tried to very briefly glance through it. And personally I had a really hard time getting into it. Having read the comparison document beforehand I haven't found anything about IPv4, IPv6, HMACs, wide-metrics or other things that are mentioned in the draft (and that ISO standard was ~200 pages already). You need RFC 1195, RFC 3719, RFC 3787, RFC 5304, RFC 5305, and RFC 5308. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet Hint: RFC 1195 does a better job explaining what ISIS does than ISO 10589. Read RFC 1195 first. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-mrw-homenet-rtg-comparison-01
In message 48cf8896-1924-493e-aefe-ce393347c...@iki.fi Markus Stenberg writes: On 2.3.2015, at 5.12, Curtis Villamizar cur...@ipv6.occnc.com wrote: Most important is that if this were to become a WG doc and the WG has for some reason excluded OSPF, this document should evaluate OSPF as well as ISIS and say why OSPF was not considered. I thought the WG more or less arbitrarily chose to make this beauty contest just limited to 2 protocols based on some live meeting comments or something. So this might be too little, too late, perhaps. Whatever the basis was for dropping OSPF should be documented somewhere. ISIS and OSPF are very similar. LSPDUs vs LSA. It affects how much stuff you have to flood when a change occurs, but the differences are minor. The real difference is OSPF runs over IP and ISIS runs over CLNP which means bringing in new Ethertype and protocol family. Note: MT might be a better solution. One TLV maps the source prefix to a topology identifier (an integer). This also maps well into the Linux and BSD implementations of multiple routing tables with an index for each routing table, and the default being zero. Perhaps another thing for the WG to discuss. draft-baker-ipv6-ospf-dst-src-routing-03 (expired) exists too. And conceptually it is exactly same as IS-IS draft with also draft-baker- prefix. I'm sure Fred would resubmit if there was interest. OSPFv3 also support IPv4 and IPv6 multicast. Any (open-source) implementations? Not open source. Cisco and Juniper and other commercial yes. Its probably in DCL or IPI code base or on their roadmap (commercial source code). Maybe it would be better to run a multicast routing protocol than ISIS, OSPF, or Babel extensions. Yes, something like PIM (or a bunch of proxies, ha ha). OK maybe the topology is simple enough and there are few enough multicast groups to just carry all multicast S,G in the unicast routing protocol. I'll concede that. 11. Implementation Status There are HOMENET implementations of both IS-IS and Babel. How do you define a HOMENET implementation? Filling the criteria above I guess. If you mean above this section in the document, then OSPF fills the criteria. There are open source implementations of ISIS, OSPF, and Babel. Some have been linked in with the openwrt code. openwrt != homenet; but its nice to see open code on a plastic router. Notably, I am not aware of a single OSPF (open-source) implementation with zeroconf and source-specific routing. Zeroconf would be easy to do. Source specific would not be quite so easy. I'm not sure if there are any open source ospf-zero-conf implementations. Anyone know? I used to maintain one originally made by Benjamin Patterson (fork of BIRD). However, I am still not aware of an implementation with the source-specific routing support which is the more painful part (especially as it essentially requires OSPF3.1, due to changing all LSAs, see draft-ietf-ospf-ospfv3-lsa-extend draft). At a guess it would be weeks-months of happy hacking for someone. I'm not convinced it would take that long. I'm going to skip this since what we should be discussing is an analysis of the amount of state needed so we don't risk making a comparison using poorly written code. A very academic point of view but I can respect that, you are not the only one with it here. This seems like a silly comparison. C code vs Erlang. For example, without reading the source code, do we know which implementation makes good use of dynamic allocation vs allocates big static arrays. This is meaningless. Cisco ISIS and OSPF used to be viable in routers with under 1MB RAM circa early 1990s with a tiny footprint. For the purpose of sizing it might be better to consider the OSPF implementations in C such as http://bird.network.cz/, http://www.openbgp.org/, http://www.quagga.net/ Certainly. Please point me to src-specific zeroconf open-source implementation of IS-IS or OSPF that is written in C. What I'm saying is that a poor implementation of a protocol is not indicitive of what the protocol is capable of. Note that the quagga ISIS is experimental. Quagga also includes Babel. For example. Bird OSPFv3 is about 12K lines of C code including both .h and .c files. Quagga OSPFv3 is 23K lines of C code. In comparison, Quagga BGP is 56k lines of code. Most of real Quagga footprint is non-routing-protocol code. For Bird it is not quite that bad, but still. If we are trying to defuse the pointless things from the document, line count is also completely BS measure, I can produce OSPF implementation in 1 line of C by taking in Bird, little preprocessing, and 1 sed command. I agree. Line count and image footprint are a poor basis for choice. In a 200 node topology there isn't a whole lot of state either. Only thing that really matters (from my point of view
Re: [homenet] 6renum redux [Routing protocol comparison document]
In message 54f26a38.8070...@gmail.com Brian E Carpenter writes: Admittedly 6renum was targetted at enterprise networks, partly because of the observation that homenets renumber anyway after every power cut. But we have spent a lot of cycles on this issue. http://tools.ietf.org/html/rfc4192 http://tools.ietf.org/html/rfc5887 http://tools.ietf.org/html/rfc6866 http://tools.ietf.org/html/rfc6879 http://tools.ietf.org/html/rfc7010 and maybe it's time to revive https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines Brian Brian, To summarize my prior inelegantly made point: Perhaps the emphasis should not be on network renumbering is hard encouraging further whining. The emphasis should not be on network renumbering does not need to be hard but can be very hard if certain bad network management practices are followed. Through some coincidence or bad karma, my colocation provider arranged for a quick demo. I was typing through an slogin when I noticed no response. To make a long story short the colo provider planned renumbered into a new IPv6 space, sent a mass email which is probably in my spam folder (to: undiclosed; bcc: ..the world..), and then did the renumber. When I called and heard about this it didn't really bother me partly since it Sunday. IPv4 still worked so I could recover. First fix all of my stored config files in one shot. foreach f ( `find * -type f | xargs grep -l 2001:550:3800` ) sed $f $f.tmp -e 's,old,new,g' mv $f.tmp $f end Then push these out to one bhyve host and two VM. gmake REMOTE_HOST=host REMOTE_USER=root SSH_AF_ARG=-4 install Then slogin to each and compare old and new: sh build-02-etc-files.sh -cmp | less After that check update it sh build-02-etc-files.sh -destdir / -targethost host Then for the VM with jails check first foreach j ( list of jail names ) sh build-03-jails.sh -cmp -destdir /j0/$j -targethost $j | less end then update /etc/rc.d/jail stop foreach j ( list of jail names ) sh build-03-jails.sh -config-only -destdir /j0/$j -targethost $j end then restart the VMs (old interface was used new one is shown): /etc/bhyve/rc.d/host restart Done with everything at the colo site. Then figure out (very easily, look in a file) who is running a caching nameserver with DNS secondaries configured to the old addresses. if it is not a jail: gmake REMOTE_HOST=host REMOTE_USER=root SSH_AF_ARG=-4 install if it is a jail then on the supporting host: sh build-03-jails.sh -config-only -destdir /j0/host -targethost host then ssh host -l root /usr/local/etc/rc.d/named stop ssh host -l root rm -f /etc/named/s/* ssh host -l root /usr/local/etc/rc.d/named start Done with all hosts Now just fix DNS glue records at the registrar and done. The whole thing was under two hours including adding the SSH_AF_ARG support to a bunch of gmake .mk files. 2 rackmount servers 1 destop (DNS only) 4 VM on the 3 rackmounts 16 jails on the 4 VMs rebuild zone files, named.conf (part of the gmake) update sendmail config files all system files such as rc.conf and sshd_config web server config including virtual host configs unaffected were kdc and svn server (no fixed addresses). This was all done remotely (since I still had working IPv4). Not terribly painful. But it could have been. Not planned, but a quick demo of renummbering something that looks a bit more like an enterprise network than a homenet (because it is). Curtis ps- and no these gmake files and perl and shell stuff is not yet available anywhere. Sorry. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
In message CAGnRvuqTphM9c=kzjrldtxeuo1doo9qp_kfmjk49ahnbzrx...@mail.gmail.com Henning Rogge writes: On Sun, Mar 1, 2015 at 5:08 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: Henning, That sounds like a good strategy. Negotiating a rate among two parties is not a hard protocol problem, nor is changing it. Note that PPP LQM (link quality monitoring) or MPLS-TP LM (loss monitoring) is not probe data. For example, one cycle of LQM packet every 10 seconds yields the exact number of packets sent and recieved and the exact number dropped in both directions over a 10 second period. One cycle is three packets, with two in one direction. The Neighborhood Discovery Protocol (RFC 6130) has a similar mechanism... each node collects local link quality information and then shares them from time to time with all neighbors, which means everyone knows about both directions of a link. Henning Rogge RFC 6130 uses probes (hello message success rate). For example: If an AP sends 100 packets a second to a neightbor and 5 drop it would be better to send one LQM packet and know that loss is 5% rather than have to send 100 hello packets in addition to the 100 data packets to reliably know that loss is 5%. (In MPLS it could be a billion packets between LM packets). LQM does not rely on a count of probe packet success. Please reread what I sent earlier or read about PPP LQM or MPLS-TP LM OAM. Please compare RFC 6130 section 14.2 (Basic Principles of Link Quality) with RFC 1989 and RFC 6375. In RFC 6375 look at Section 2.2 (Packet Loss Measurement) and Section 3.1 (Loss Measurement Message Format). RFC 6130 has no comparable mechanism. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] draft-mrw-homenet-rtg-comparison-01
Hi, This is a review of draft-mrw-homenet-rtg-comparison-01. Thanks for the good work. Curtis A note of format of this email. I've used the OLD: and NEW: markers rather than unified diff. I indented the works OLD and NEW with one space. When quoting text, I indented the section headings two spaces to make it clear it is quoted text. The body of the text is indented three spaces as done in the internet-draft txt file. Most important is that if this were to become a WG doc and the WG has for some reason excluded OSPF, this document should evaluate OSPF as well as ISIS and say why OSPF was not considered. Abstract This document is intended to provide information to members of the IETF Home Networks Working Group (HOMENET WG), so that we can make an informed decision regarding which routing protocol to use in home networks. The routing protocols compared in this document are: The Babel Routing Protocol (Babel) and The Intermediate System to Intermediate System Intra-Domain Routing Protocol (IS-IS). I will comment on this document with the assumption that OSPF will be covered in the future. So starting with the abstract, please addd OSPF. 1. Introduction This document compares IS-IS (ISO/IEC 10589:2002) [RFC1142] and Babel [RFC6126] according to several criteria related to their use in home networks (HOMENETs), as defined by the HOMENET WG. Again, please add OSPF. Please note that this document does not represent the consenus of any group, not even the authors. It is an organized collection of facts and well-informed opinions provided by experts on Babel and IS-IS that may be useful to the HOMENET WG in choosing a routing protocol. This document would be a useful document if it were accurate and became a WG document. A final section with WG recommendations could be added (optional) if there were WG concensus. OLD: The HOMENET environment is different from the environment of a professionally administered network. The most obvious difference is that a HOMENET is not administered: any protocols used must be robust and fully self-configuring, and any tuning knobs that they provide will be unused in the vast majority of deployments. NEW: The HOMENET environment is different from the environment of a professionally administered network. The most obvious difference is that the vast majority of home networks are not administered: any protocols used must be robust and fully self-configuring, and any tuning knobs that they provide will be unused in the vast majority of deployments. The option to augment protocol mechaisms with configuration is needed in a subset of home networks, small home offices, or small businesses which may use the mechanisms designed with the HOMENET environment in mind. At the very minimum, it should be possible to provide configuration to insure robust network security. DIFF: Not all homenets will be configuration free. Homenet should also be applicable to soho and small business. At the very least security configuration (keys, passwords, pass phrases) should be configurable. We don't want HOMENET and security to be mutually exclusive. OLD: Contrary to popular perception, the Plastic Home Router is usually equipped with a reasonably fast CPU and reasonable amounts of flash and RAM; at the time of writing, a (non-superscalar) 700MHz MIPS CPU with 16MB of flash and 64MB of RAM is typical. However, we expect smaller devices to participate in the HOMENET protocols, at least as stub routers. The ability to scale down the HOMENET protocols is therefore likely to encourage their wider adoption. NEW: Contrary to popular perception, the Plastic Home Router is usually equipped with a reasonably fast CPU and reasonable amounts of flash and RAM; at the time of writing, a (non-superscalar) 700MHz MIPS CPU with 16MB of flash and 64MB of RAM is typical. However, we expect smaller devices to participate in the HOMENET protocols, at least as stub routers. The ability to accomodate routers with limited capability as well as legacy routers and switches will encourage wider adoption. Legacy Ethernet routers which can only NAT from an assumed WAN port and act as an Ethernet switch on an assumed LAN side may only be useful as an Ethernet switch, but only if their DHCP server can easily be disabled. Some legacy Wifi routers may only be useful as a stub WiFi AP, performing an unecessary redundant NAT. DIFF: Last sentence become a new paragraph. The new text (or some concensus variation) may provide better description of the usefulness (or lack of) of limited functionality homenet devices and legacy devices. Note on this: [Isn't it also the case that the HOMENET routing protocol will be implemented on lower-end embedded devices, such as nodes in a low- power wireless network? What
Re: [homenet] 6renum redux [Routing protocol comparison document]
In message 54f26a38.8070...@gmail.com Brian E Carpenter writes: Admittedly 6renum was targetted at enterprise networks, partly because of the observation that homenets renumber anyway after every power cut. But we have spent a lot of cycles on this issue. http://tools.ietf.org/html/rfc4192 http://tools.ietf.org/html/rfc5887 http://tools.ietf.org/html/rfc6866 http://tools.ietf.org/html/rfc6879 http://tools.ietf.org/html/rfc7010 and maybe it's time to revive https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines Brian Hi Brian, I'm sort of vaguely aware of this stuff on renumbering and of course you are an author of much of it. Some comments on this. btw- this thread is almost certainly on the wrong WG mailing list so if you'd like to redirect it, that would be a good thing for homenet. It seems to be entirely enterprise renumbering focused. Therefore I've dropped the WG from the Cc for now. The opsarea-ipv6-renumbering-guidelines draft seems like a bad starting point. For one thing the advice is change DNS first (break everything) and then renumber. No mention of dropping TTL to the minimum first which would be less bad, but still bad (minimum 15 minute outage). Oh wait ... that is essentially the topic of RFC 4192. Just cite RFC 4192. If it is a provider or enterprise renumber, then two prefixes are available. First add aliases allowing everything to be reachable using either the old or new address. Test. Then change DNS. Retest. Then long after DNS caches have the new entry, drop the old addresses. Retest should not be necessary but retest anyway. Don't bother with ULAs unless there is no way to get a globally routeable address. Both routers and hosts with modern operating systems support numbering the loopback. These usually also support configuring the IPv6 preference to make binding to the loopback preferred without the source code changes that used to be required in IPv4 years of old. Perhaps RFC 2894 is a candidate for historic. It is much easier to use RA and advertise the old prefix with a prefered lifetime of zero. Not that routers today take advantage of either AFAIK. RFC 5887 mentions both using RA and using DHCPv6 FORCERENEW or RECONFIGURE for renumbering. Is the use of RA M bit with no prefix or O bit with prefix still considered ambiguous? nit: Does anything really have a 128 bit DIP switch to set IPv6 address as implied in RFC 5887? Certainly configured in flash exists, but DIP switch. In RFC 5887 section 7. There is no need for address lifetimes in the socket API if applications don't use bind to set the source address. RFC 5887 7.1 : FORCERENEW in particular requires DHCP authentication [RFC3118] to be deployed. Really? I can see why since it could be used in a DoS attack if the host didn't rate limit renewals. But if it did rate limit renewal ... In RFC 5887 7.2 - ISPs have figured out how to renumber. Most already generate configurations and push them out automatically even if that means using a variety of proprietary methods (CLI). And yes, netconf is a good starting point but there may only be a problem for small routers and/or smaller deployments that still hand configure. I'm not sure that RFC 6866 and RFC 6879 add much value. RFC 7010 does add value but IMHO not much. Perhaps the emphasis should not be on network renumbering is hard encouraging further whining. The emphasis should not be on network renumbering does not need to be hard but can be very hard if certain bad network management practices are followed. First keep track of everything that is configured, save the configuration, and know how to reach that device to reconfigure it. This includes DHCP servers. aside type=semi-rabid-rant !-- no reply please :) -- For example, even for my home net I have a SVN controlled directory known as system-files. It has every configuration file (boot/loader.conf, /etc/fstabs, /etc/rc.conf, /etc/mail/*, dhcpd.conf, rtadvd.conf, etc). It also has shell scripts for anything supporting an automatable access to configs to compare the running config files on a host to the stored ones or to update the config. Renumbering was a breeze - update all configs, mostly with emacs macros, then push out new configs. I did not have the luxury of a transition period but I used the old addresses while updating and making the transition to the new addresses. I set this up this way because I had worked for an ISP and know that if they had 2,000 things and didn't know where they were, what configs they were running, or how to change them remotely, they would have never survived. Not everyone running an enterprise network has the benefit of that prior experience. And we certainly can't expect anyone in a homenet to ever do this which is a big part of why we are here. And yes, all my rackmount servers and VMs and jails and desktop are static configured. Nothing is dynamic except those things connecting on WiFi,
Re: [homenet] 6renum redux [Routing protocol comparison document]
In message 54f26a38.8070...@gmail.com Brian E Carpenter writes: Admittedly 6renum was targetted at enterprise networks, partly because of the observation that homenets renumber anyway after every power cut. But we have spent a lot of cycles on this issue. http://tools.ietf.org/html/rfc4192 http://tools.ietf.org/html/rfc5887 http://tools.ietf.org/html/rfc6866 http://tools.ietf.org/html/rfc6879 http://tools.ietf.org/html/rfc7010 and maybe it's time to revive https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines Brian Oops. Didn't actually drop the Cc on prior email. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
In message CAGnRvurm5wDMVxdvHy6rdvkPkwQ2q_YHcZiU0+NLmq=zpay...@mail.gmail.com Henning Rogge writes: On Sun, Mar 1, 2015 at 12:52 AM, Curtis Villamizar cur...@ipv6.occnc.com wrote: If any of the control packets drop, drop a partial result, repeat later, and compare to the last complete result. Is one cycle per neighbor too much? How about one cycle per neighbor each 5 seconds? If B is the AP it sends only one packet per cycle but both sides get accurate drop rate for both directions. I went even further and restricted the probing to a fixed amount per interface... to prevent the wifi network from overloading in crowded adhoc networks (where everyone can see everyone). Henning Rogge Henning, That sounds like a good strategy. Negotiating a rate among two parties is not a hard protocol problem, nor is changing it. Note that PPP LQM (link quality monitoring) or MPLS-TP LM (loss monitoring) is not probe data. For example, one cycle of LQM packet every 10 seconds yields the exact number of packets sent and recieved and the exact number dropped in both directions over a 10 second period. One cycle is three packets, with two in one direction. IMHO an LQM for WiFi would be a good idea. It would have to be specified and coded (though coded and then specified seems to be the model that some people prefer). Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
In message caa93jw7yyj4ouagsed-dn4ttvkuwucyloqdsqxpho4af+3h...@mail.gmail.com Dave Taht writes: On Fri, Feb 27, 2015 at 1:37 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: In message cagnrvupwf3n9jqmi_txwbxketo_59zdqqapcfcsyfduvqp8...@mail.gmail.com Henning Rogge writes: On Wed, Feb 25, 2015 at 9:36 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: In message 87a903ef2j.wl-...@pps.univ-paris-diderot.fr Juliusz Chroboczek writes: As to wireless links -- as far as I'm aware, making efficient use of wireless L2 information in a routing protocol is an open research problem. Other than signal strength and collision rate, what L2 information is available? Per MAC information would be nice for the AP side or any node in mesh or adhoc mode but that isn't collected anywhere AFAIK. Raw linkspeed and (on Linux) even Throughput to each neighbor... and a lot more. Just run iw wlan0 station dump on a Linux system with wifi and you will be surprised how much information you will get. Henning Rogge Henning, How can a router make use of throughput to a mostly idle neighbor? How do you get packets sent to a neighbor that dropped or packets that a neighbor sent to you that didn't arrive here? Raw link speed or packet and byte counts don't by themselves tell you much. The equivalent of PPP LQM or MPLS-TP LM OAM would be the sort of thing needed is you didn't want to use BFD with a high probe rate. As I said above (or tried to say), the most useful hints that the link isn't as good as nominal link speed might indicate might be signal strength and collision rate. [What I meant above by available was available and useful for making efficient use of wireless L2 information in a routing protocol in the quoted text. So maybe I was too terse in saying that.] Thanks for the response though. I use FreeBSD and other than rate and S/N there isn't much, so could you send me sample output from a Linux host or better yet a Linux AP with a few neighbors. We can take this off list and discuss the sample output but so far lots of stuff (sic) doesn't help. Curtis ps - maybe I should stop procrastinating and compile and flash openwrt and see for myself, but for now ... You don't have to compile a thing, just download the right nightly from chaos calmer (preferred as hnetd etc are in it), and flash it. Everyone here, has been 90 bucks, 5 minutes and one reflash away from eating it's dogfood for 9+ months now. http://downloads.openwrt.org/snapshots/trunk/ Dave, I do need to compile if I prefer to try some of my own recipes for dog food. Not that I don't also want to try yours. I'm more interested in Ethernet than WiFi for my home use. WiFi is sort of like the penalty box here. It works fine for normal web browsing and such. If I want to move more than just a few bits around I plug the laptop into a GbE port somewhere. btw- You do have an advantage in any discussion based on running code. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
In message caa93jw4tumfm_lvzkrx7ark2z+hwtw5jboenpvfejut4l9t...@mail.gmail.com Dave Taht writes: On Fri, Feb 27, 2015 at 2:00 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: In message 54ee258e.8060...@gmail.com Brian E Carpenter writes: On 26/02/2015 05:14, Mikael Abrahamsson wrote: On Wed, 25 Feb 2015, Ray Hunter wrote: That way the devices can roam at L3, without all of the nasty side effects of re-establishing TPC sessions, or updating dynamic naming services, or having to run an L2 overlay network everywhere, or having to support protocols that require a specialised partner in crime on the server side (mTCP, shim6 et al). It's my firm belief that we need to rid clients of IP address dependence for its sessions. Asking clients to participate in HNCP only addresses the problem where HNCP is used. Fixing this for real would reap benefits for devices moving between any kind of network, multiple providers, mobile/fixed etc. Violent agreement. This is not a homenet problem; it's an IP problem. In fact, it's exactly why IP addresses are considered harmful in some quarters. Trying to fix it just for homenet seems pointless. http://www.sigcomm.org/ccr/papers/2014/April/000.008 Brian Brian, Seriously - your paper may be overstating the problem. At least if we discount IPv4 and in doing so eliminate NAT we solve a lot of problems that never should have existed in the first place. If we carry NAT over to IPV6, then shame on us. I am sorry, I no longer share this opinion. The pains of renumbering someones entire home network every time the ISP feels like it, given the enormous number of devices I have encountered that don't handle it well, are just too much to bear. I renumbered 140.222/16 into 147.225/16 in the mid 1990s (T3-NSFNET to ANSNET as part of the NSFNET decommissioning). Not by myself of course, but there were only a few of us on this. It wasn't all that bad and we had about 2,000 things to renumber in hundreds of locations, many of them not manned. Shell scripts and ksh (kerberized rsh, not the Korn shell) made it simpler. The worst was Cisco routers and various old DSU/CSU and other commercial stuff since you had to use expect scripts on their CLI rather than just something of the form ksh fqdn -l root ifconfig newaddr/mask alias People with root on their workstation that didn't give us acess were given notice. We used interface aliases and gradually took down the old aliases and subnet addresses. Nothing critical was affected. It took a day or two, then bake time, then less than a day to remove aliases. OTOH - Most homes can't run two prefixes for a week or two before taking the old prefix down. And lots of consumer devices don't do aliases. But now days there is DHCP which didn't exist then (and ICMPv6 RS/RA and SLAAC). Are you having problems with the provider not giving you a static IPv6 prefix, but rather changing it on a whim? I also renumbered my home net multiple times, but again, not much pain. Only a few consumer gadgets here have fixed addresses (one because it never renewed DHCP leases and therefore needed a fixed address, but that has since been tossed in e-waste recycling). 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. Are you suggesting that we add NAT to IPv6? [I ask with disbelief.] I would definitely be turning that off since I have a plenty big and very static IPv6 prefix. I also have a (tiny) static IPv4 prefix so I have no choice but to IPv4 NAT due to its tiny size. A better option might be to use something that switches over faster than a DHCP lease times of days. It seems that ICMPv6 RA can be sent with prefix prefix information TLV with valid lifetime and/or preferred valid lifetime of zero. This is in RFC 4861 on Page 55: - If the prefix is already present in the host's Prefix List as the result of a previously received advertisement, reset its invalidation timer to the Valid Lifetime value in the Prefix Information option. If the new Lifetime value is zero, time-out the prefix immediately (see Section 6.3.5). Would that help? Also, stateful DHCPv6 can invalidate leases (me thinks)? Maybe DHCPv4? Am I mistaken about that? I am sure this will break stuff, and I don't know what all it will do, and I intend to find out. Just breaks the end-to-end principle and requires rendezvous and all that ugliness. IMHO it would be better to send an immediate RA with a zero lifetime on the old prefix and a normal lifetime on the new prefix. If hosts don't do the right thing they are in violation of RFC 4861. OTOH, invalidating a DHCP lease
Re: [homenet] L2 link status [was: More about marginal links]
In message CAA93jw627Q12XkZy3CFuV81CLbJc5D9oX6LK1=cgetwsop1...@mail.gmail.com Dave Taht writes: BFD, Hellos, or any form of probe traffic over wireless has the speed of detection vs overhead issue. At nominal 10 Mb/s (low end today for wireless) a small probe would take about 0.1 msec (for example, 125 bytes including all overhead is about 1000 bits). Not bad if running 100 probes/sec (30 msec detection) unless there are a very large number of stations using the AP and doing the same thing. In that You are thinking about it wrong. Wireless-g is only capable of roughly 1300 TXOPs total per second. Bandwidth has NOTHING to do with it. I don't have the figure in my head for n or ac, but it is not a lot, and in the presence of g, falls back to the above figure. losing 10% of the bandwidth - per station - to run BFD is not an option. case 10 probes per second might be better. A very high collision rate Still too much. Next question? Oops yeah. You are right. Forgot about TXOPs. How about a PPP LQM / MPLS-TP LM OAM equivalent? Briefly: A sends pkt/byte sent to B. B notes pkt/byte recv and adds that to the packet. B adds its pkt/byte sent and sends that back to A. A notes its pkt/byte recv and sends back to B. A saves this. B simply receives and saves this. Save prior packet, wait some time, and then repeat: Now subtract the two sets of counter (new - old packet). Each side compares other side sent to their own received. Difference is number of packets dropped. Repeat forever using prior result to update drop rate. If any of the control packets drop, drop a partial result, repeat later, and compare to the last complete result. Is one cycle per neighbor too much? How about one cycle per neighbor each 5 seconds? If B is the AP it sends only one packet per cycle but both sides get accurate drop rate for both directions. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
In message 17359.1424897...@sandelman.ca Michael Richardson writes: Ray Hunter v6...@globis.net wrote: I agree that WiFi roaming is a problem that needs addressing in Homenet. Yes, but can we rule it out of scope for now? Can we agree that it's not strictly a routing problem, and that the set of solutions that we are considering could be used, and that we could also explain how to do something like automatically setup capwap using HNCP for discovery, but that we don't have the head-of-queue block on this item for now? -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- Perhaps consider it two problems, roaming within an administrative domain and roaming into another administrative doamin. The latter is harder to solve. Other than bridging all of the AP within an administrative domain, there is no way to support the former without at least some host change. As I mentioned before, I favor putting a /128 on the loopback and having the routers/APs forward to the interface address of the moment to that /128. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
In message cagnrvupwf3n9jqmi_txwbxketo_59zdqqapcfcsyfduvqp8...@mail.gmail.com Henning Rogge writes: On Wed, Feb 25, 2015 at 9:36 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: In message 87a903ef2j.wl-...@pps.univ-paris-diderot.fr Juliusz Chroboczek writes: As to wireless links -- as far as I'm aware, making efficient use of wireless L2 information in a routing protocol is an open research problem. Other than signal strength and collision rate, what L2 information is available? Per MAC information would be nice for the AP side or any node in mesh or adhoc mode but that isn't collected anywhere AFAIK. Raw linkspeed and (on Linux) even Throughput to each neighbor... and a lot more. Just run iw wlan0 station dump on a Linux system with wifi and you will be surprised how much information you will get. Henning Rogge Henning, How can a router make use of throughput to a mostly idle neighbor? How do you get packets sent to a neighbor that dropped or packets that a neighbor sent to you that didn't arrive here? Raw link speed or packet and byte counts don't by themselves tell you much. The equivalent of PPP LQM or MPLS-TP LM OAM would be the sort of thing needed is you didn't want to use BFD with a high probe rate. As I said above (or tried to say), the most useful hints that the link isn't as good as nominal link speed might indicate might be signal strength and collision rate. [What I meant above by available was available and useful for making efficient use of wireless L2 information in a routing protocol in the quoted text. So maybe I was too terse in saying that.] Thanks for the response though. I use FreeBSD and other than rate and S/N there isn't much, so could you send me sample output from a Linux host or better yet a Linux AP with a few neighbors. We can take this off list and discuss the sample output but so far lots of stuff (sic) doesn't help. Curtis ps - maybe I should stop procrastinating and compile and flash openwrt and see for myself, but for now ... ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
In message 54ee258e.8060...@gmail.com Brian E Carpenter writes: On 26/02/2015 05:14, Mikael Abrahamsson wrote: On Wed, 25 Feb 2015, Ray Hunter wrote: That way the devices can roam at L3, without all of the nasty side effects of re-establishing TPC sessions, or updating dynamic naming services, or having to run an L2 overlay network everywhere, or having to support protocols that require a specialised partner in crime on the server side (mTCP, shim6 et al). It's my firm belief that we need to rid clients of IP address dependence for its sessions. Asking clients to participate in HNCP only addresses the problem where HNCP is used. Fixing this for real would reap benefits for devices moving between any kind of network, multiple providers, mobile/fixed etc. Violent agreement. This is not a homenet problem; it's an IP problem. In fact, it's exactly why IP addresses are considered harmful in some quarters. Trying to fix it just for homenet seems pointless. http://www.sigcomm.org/ccr/papers/2014/April/000.008 Brian Brian, Seriously - your paper may be overstating the problem. At least if we discount IPv4 and in doing so eliminate NAT we solve a lot of problems that never should have existed in the first place. If we carry NAT over to IPV6, then shame on us. If we get rid of NAT a big part of the problem just goes away. No alternate spaces, kludgy rendezvous mechanisms, etc. Using an address on the loopback gets rid of the multiple interface problem and where it really matters (ISP router and ISP or DS server reachability) this has been done with configuration for two decades. The multihoming failover or roaming are a bit more difficult but things MPTCP is supposed to address. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
In message 87a903ef2j.wl-...@pps.univ-paris-diderot.fr Juliusz Chroboczek writes: Thought: In general, my feeling is that L2 link status is widely relied upon in commercial product/dpeloyments. If homenet feels it can not rely on it due to the non-commercial nature of its development platforms, thats an interesting aspect, especially because it could impact an IETF standard that we'd like to see commercially implemented and then the constraints could be different... Are you referring to the routing protocol comparison, or to something else? I have the impression that Babel and IS-IS behave essentially the same wrt. L2 status -- they both converge fast enough after link status has been established, and they essentially provide the same facilities for application-layer link sensing (IMHO Babel's Hello/IHU subprotocol is slightly more flexible, but that's probably not a big deal). As to wireless links -- as far as I'm aware, making efficient use of wireless L2 information in a routing protocol is an open research problem. Other than signal strength and collision rate, what L2 information is available? Per MAC information would be nice for the AP side or any node in mesh or adhoc mode but that isn't collected anywhere AFAIK. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ISPs mostly use Ethernet as point-to-point (PTP) links. Including using 100GbE as PTP. No switches. L2 Link down is one fast indicator of link down. But for Ethernet over transport gear (ie: OTN) BFD is almost always used. For short distances L2 over extended reach optics can be used, including colored optics and WDM. This is also PTP and in this case BFD should not be needed. To the extent that routers use SONET or OTN interfaces, these have fast L2 link down indication and are integrated with L3 link down detection. In all of these detection is on the order of 10 msec (geographic distance dependent), failover using FRR is under 50 msec, and IGP convergence is well under a second (typical 100-200 msec today AFAIK). L3 hellos are way too slow. BFD is not heavy weight. L3 hellos (OSPF, ISIS) can be set down to 1s with detection in 3s (too slow). BFD, Hellos, or any form of probe traffic over wireless has the speed of detection vs overhead issue. At nominal 10 Mb/s (low end today for wireless) a small probe would take about 0.1 msec (for example, 125 bytes including all overhead is about 1000 bits). Not bad if running 100 probes/sec (30 msec detection) unless there are a very large number of stations using the AP and doing the same thing. In that case 10 probes per second might be better. A very high collision rate (typically not due to probes, but to real traffic) might result in a link down indication. If that is the case, then moving to another AP would be a good thing. Flapping needs to be avoided if an alternate is available (ie: with 20% loss, in .2*.2*.2 = .008 = 0.8% of intervale a down indication would occur). If any packet received would bring it back up, then at 100 probes / sec, a change in IGP link state could occur about once a second on average. Remembering a link down and holding a down state for a (longish) while would be a good thing. If there is no alternate route, not probing at all and/or holding an up state would be good. OTOH- 20% loss borders on completely unusable. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Roaming hosts [was: Routing protocol comparison document]
In message caestavvjazomppfgoigtaranueokeb5hhmkfgnae-v31+ro...@mail.gmail.com Mark Townsley writes: When a host connects to a different link covered by a different subnet, indeed it will require a new IP address. That's pretty fundamental to what a subnet is. Hosts are getting better and better at handling multiple addresses, of both versions, coming and going. MPTCP should continue to help in this regard. I'm a big fan of seeing more and more MPTCP, and I've been impressed at the ability of modern devices to upgrade their host stacks in the past 4-5 years (vs. the decade or so before). I'll remain cautiously hopeful here for the long term. In the mean time, I fully expect that to support seamless wifi roaming from one AP to another there will have to be some sort of bridging or tunneling (capwap, et. al) taking place to keep the single ethernet wifi subnet alive for IPv4 and less modern IPv6 hosts. That doesn't mean there will be no room for routing in the home, as one of the primary motivations for IP routing is to support diverse media types. i.e, it's much easier I think if wi-fi only has to worry about roaming within wi-fi, and not MOCA, EoPL, 802.15.4, Bluetooth LE, etc. as well. One day if/when hosts and apps finally become fully resilient to IP address changes, then it could become much easier on APs as they will have the chance to simply hand out a new IPv6 address and route, avoiding bridging and/or tunneling tricks. That could be a nice win for wifi scalability, but to be honest is shrouded in so many operational practicalities and moving parts that it's best not to try pretend that this will come to pass even if we are successful in providing the world with zero-touch IP routing technology in the home. It could be a very nice bonus, and I hope it happens, but I wouldn't want to set the bar that high in the near term as something homenet can make happen on its own. - Mark The way this was solved circa early-mid 1990s (with configuration required and a bit of code hack) involved putting a fixed address on the loopback interface. For incoming TCP connections, only an ifconfig lo0 was required. For outbound TCP connections, no MPTCP was needed, just an ability to favor binding to the loopback address on critical applications where an outbound connection is made. This was the code change needed back then (and was tupically done to klogin, and the other kerberos enabled r-commands). Today, with address selection policy (ie: ip6addrctl on BSD), no code changes are needed for outbound TCP connections as well. This type of allocation would work if moving from one AP to another within an administrative domain (within a homenet or from an office to a conferance room at work) but not when roaming from home to the coffee shop wifi AP. Here is one way it might get done. It might be worth considering a multiple means to hand out addresses for lookbacks. For example extensions to DHCP, SLAAC, DHCPv6, would require only minimal host changes. Hosts could also run OSPF and be stub routers (can be dual or multi homed, but no transit). A router can use OSPF link local addresses as it does today and make an implicit request for a loopback address. The implicit request is made by its existance in the topology with no routable address. Allocation can be by the CPE at a provider border for the router itself, mapping OSPF or ISIS router-id to the requested prefix. Explicit requests can be made using a TLV with a MAC associated with a DHCP lease. Together these two TLVs imply a /32 or /128 stub. If a host is dual homed and gets information from DHCP, then when making a request on a second interface, its already allocated /32 and/or /128 or its other MAC can be included in the DHCP request to avoid a second allocation. The router could then advertise an alternate way to reach that loopback. The host would now be a stub reachable via two routers. For the benefit of older OSPF or ISIS implementations if there were such a thing in the home, any /32 or /128 stub can be explicitly advertised into the LSDB. I don't expect a homenet to get overrun with /128 addresses in the OSPF or ISIS LSDB. Hosts with a /128 on its own loopback would use the default route to get to other stubs within the same /64 as its loopback. This would only be updated hosts, so it would be safe to assume they won't make the /128 into a /64. Note that hosts then don't require routeable interface addresses, only an address on the loopback. This works within an administative domain and doesn't require that the other side of a TCP connection to be upgraded (as is the case with MPTCP). There are no TCP stack changes required, but also implementing MPTCP won't hurt when wandering to the coffee shop. Old hosts works as they did before. They get two interface addresses. As long as they send traffic to an interface that is up and gave it a default route things should work. Switch over based on lease
Re: [homenet] HNCP security?
Brian, et al, L2 never really was secure, regardless of whether we are talking about enterprise or home networks, wired or wireless. Sure there was a firewall in place, but the L2 and the subnet behind the firewall was only as secure as the least secure device that ever connected to it. Which is to say, not at all secure. I have yet to work at a corporation since the mid-1990s that didn't at some point have IT report that the local network was clogged due to a virus run rampant behind the firewall. This has always applied to both wired and wireless networks. Perhaps it is worse with wireless since any laptop or cell phone able to connect is a potential breach that can be leveraged if L2 security is assumed. [So I'm agreeing with Brian, but pointing out that wired L2 was never secure in the first place.] Curtis In message 5414a96c.2050...@gmail.com Brian E Carpenter writes: On 13/09/2014 17:40, Markus Stenberg wrote: On 13.9.2014, at 5.50, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 12/09/2014 22:23, Markus Stenberg wrote: ... 1) Can we assume secure L2 and/or appropriate device configuration by the manufacturer/ISP(/user)? (This is what I can assume in my own home.) I'm not sure I fully understand this question, but certainly there a vast numbers of insecure home 802.11 setups. This is less prevalent than it was a few years ago, but it seems like a dangerous assumption if homenet-compliant kit is mixed in with older stuff such as wireless hubs that are open by default. From my point of view, if youâre exposing part of your home network via insecure wireless, only way to secure it would be to run mandatory crypto over it both to hosts and routers. Iâm not sure this is really feasible either. Just securing router-router traffic (or parts of it) does not bring significant benefit from my point of view unless you also authenticate hosts in such a case. All true (as are the subsequent comments by Acee and Michael). But the fact remains that we can't assume L2 is secure in the normal case, which is a much worse situation than we traditionally assumed for wired networks. Brian While securing HNCP in such a case would prevent some attacks on in-home network auto-configuration, anything else (e.g. using home resources, using home internet access, pretending to be uplink and performing MITM, the list goes on) would be still possible and I do not see the point. Cheers, -Markus. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] fwd: draft-ietf-homenet-arch-04
In message 506c889b.4070...@centurylink.net Jeff Bowden writes: Curtis, I agree with your addition of that paragraph with the one exception of removing the at no additional cost phrase. I agree it should be that way but it is up to the individual ISP and not the IETF as to what should and should not be charged for. Yes, lets move on. Best regards, Jeff Bowden The at no additional cost phrase is consistent with RFC6177. See first paragraph in section 2 2. On /48 Assignments to End Sites. Looking back at some of the original motivations behind the /48 recommendation [RFC3177], there were three main concerns. The first motivation was to ensure that end sites could easily obtain sufficient address space without having to jump through hoops to do so. For example, if someone felt they needed more space, just the act of asking would at some level be sufficient justification. As a comparison point, in IPv4, typical home users are given a single public IP address (though even this is not always assured), but getting any more than one address is often difficult or even impossible -- unless one is willing to pay a (significantly) increased fee for what is often considered to be a higher grade of service. (It should be noted that increased ISP charges to obtain a small number of additional addresses cannot usually be justified by the real per-address cost levied by RIRs, but additional addresses are frequently only available to end users as part of a different type or higher grade of service, for which an additional charge is levied. The point here is that the additional cost is not due to the RIR fee structures, but to business choices ISPs make.) An important goal in IPv6 is to significantly change the default and minimal end site assignment, from a single address to multiple networks and to ensure that end sites can easily obtain address space. The phrase SHOULD provide these shorter prefixes at no additional cost is much shorter, more direct, and after all is only a SHOULD. There is no justification to charge more for a shorter prefix than /64 other than providers tendency to charge for anything they can charge for even if there is no incremental cost to them. I think that phrase should stay. btw- At some prefix length (maybe shorter than /56 or /48) it is not unreasonable to expect some form of justification. After all, a /56 provides 256 subnets and a /48 provides 64K subnets and that is a lot of subnets for a home or soho or small business. Curtis On 10/3/2012 12:36 PM, Curtis Villamizar wrote: In message 506be6ae.5070...@globis.net Ray Hunter writes: Why not just add RFC 6177 BCP 157 http://www.rfc-editor.org/bcp/bcp157.txt as a normative reference in draft-ietf-homenet-arch? That's a lot shorter than re-hashing the whole discussion within Homenet. Clearly some providers aren't getting it so repitition may help, but not repitition of the entire argument made in RFC6177. For example: This document obsoletes RFC 3177, updating its recommendations in the following ways: 1) It is no longer recommended that /128s be given out. While there may be some cases where assigning only a single address may be justified, a site, by definition, implies multiple subnets and multiple devices. One provider is doing a trial allocating /128 addresses and alegedly targeting this at *business service*. /64 later (no date). shorter prefixes still later (also no date). So either they are not reading RFC6177 or they are not getting it. Wording which refers to RFC6177 would help. Adding the one sentence below to that would also help. How about: If home networks are to avoid having to subdivide /64s, then consumer oriented service providers MUST allow customers to easily request and get prefixes shorter than /64 and SHOULD provide these shorter prefixes at no additional cost. Allocation of shorter prefixes than /64 is recommended in RFC 6177 BCP 157 [RFC6177]. If there is no objections we can end this part of the thread and move on to the rest of the suggested changes to the draft. Curtis Villamizar wrote: Now that we beat summary item #12 to death, can we please turn our attention to the remaining 18 summary items listed below and the diffs to the draft? btw- I think the concensus on summary item #12 is that maybe we can add the following points to the framework. Subnets longer than /64 are bad. Some devices don't support DHCPv6, therefore SLAAC is essential. Consumer oriented service providers of must allow customers to easily request and get prefixes shorter than /64 and preferably at no additional cost if we are to avoid having to subdivide /64s. Curtis [ ... trim ... ] I think your reply was just concerning the above paragraph so I
Re: [homenet] draft-ietf-homenet-arch-04
IPv4 Proxy-ARP never scaled well and was highly problematic. RFC4903 is informational and merely records some history. It also recommends that link types mcast, ptp, nbma, be used and specifically states A multi-link subnet model should be avoided. I don't think MANET and RPL violate the generally accepted definition of subnet. For example, Ethernet bridges do not violate the notion of IP subnet if they run STP or other protocol to learn MAC addresses within the subnet. To IP this is one logical mcast link. MANET is largely experimental (ie: RFC5449, RFC5614, RFC5820, others are experimental). RPL (RFC6550) is more closely analogous to a bridging protocol that operates over a spacific type of subnet. Possibly same with MANET. Both RPL and MANET have requirements that do not apply to the homenet that is running Ethernet and WiFi. If a LOWPAN island running RPL wants to be a single subnet, reachable from the Ethernet and WiFi subnets, that is fine. Some issues may exist if one of the LOWPAN devices is moved out of range or powered off and an RPL island is split into two RPL islands. The use of a single subnet as used in RPL/MANET is specifically discouraged in RFC4903. Curtis In message 506b0d3e.80...@gridmerge.com Robert Cragie writes: This is a cryptographically signed message in MIME format. --===5925802905536615095== Content-Type: multipart/signed; protocol=application/pkcs7-signature; micalg=sha1; boundary=ms040008020704080408030300 This is a cryptographically signed message in MIME format. --ms040008020704080408030300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Curtis, Comments inline, bracketed by RCC/RCC Robert On 01/10/2012 7:11 PM, Curtis Villamizar wrote: In message cc8ee0e5.1a5cb%d.stu...@att.net Don Sturek writes: =20 Hi Curtis, =20 On the topic of link local on each subnet and a routing protocol work= s for any topology. =20 In using 6LoWPAN with ROLL (route over), you end up with a mesh networ= k where the scope of link local address is only between a single device = in the mesh and its one-hop neighbors (not among all devices in the mesh)= =2E =20 In a 6LoWPAN/ROLL topology, we need a ULA to allow routable communicat= ions between all devices in a single mesh subnet. =20 Don Don, The subnet is meant in IETF terms, not ITU subnetwork. The subnet is therefore anything link local by definition. RCCNot in the case of RPL or MANETs. This is a multi-link subnet where = routers within the subnet are L3 forwarders (aka route over)./RCC A 6LoWPAN node can get a GUA and use the GUA (or link local address) of a router as a default route. If the 6LoWPAN device needs only site connectivity then it can use the link local address for everything. RCCAgain, not true in RPL or MANETs. As Don points out, in a RPL/MANET = network, link local means your one-hop neighbors only./RCC If a routing protocol is in use and is using link local based host routes, then a router must fake the DAD collision if a duplicate is found anywhere within the site. If a multiple ULA are used, one per subnet, then DAD is only relevant to the subnet. A router should pick a ULA prefix that is not already in use elsewhere in the site. RCCIn the multi-link subnet, typically a single ULA or GUA would be=20 used for the whole subnet including the routers. Multihoming may be=20 necessary depending on external connectivity./RCC An extremely low probability race condition exists, but it is a race condition among routers with multiple routers picking and advertising the exact same ULA prefix in the routing protocol very nearly simultaneously (within LAN flooding interval). A wait and backoff can solve this even though it is a miniscule probability. A mesh in IETF terminology is by definition multiple subnets. A subnet is by definition link local. RCCAgain, not according to RPL and MANET protocols. There does seem to = have been some discussion on this which probably needs to be resurrected = (see RFC 4903)./RCC Curtis On 9/30/12 3:36 PM, Curtis Villamizar cur...@occnc.com wrote: =20 In message cc872d11.1a2ee%d.stu...@att.net Don Sturek writes: Hi Robert, =20 One more point touched on in your note below: 1) Ideally, it would be great if a single authorizatative device existed in the home providing DHCPv6 server services (if supported) and pref= ix delegation. =20 One challenge in the description below is having multiple routers on= multiple subnets, each possibly acting as a DHCPv6 server within the= ir own subnet and also providing their own ULA prefix. =20 We certainly don't want to further confuse address assignment in a setting where IT support does not exist. =20 Don We want things to just work witb no config. Link local on each subnet and a routing protocol works for any topology. ULA just allow= s summarization
[homenet] fwd: draft-ietf-homenet-arch-04
Now that we beat summary item #12 to death, can we please turn our attention to the remaining 18 summary items listed below and the diffs to the draft? btw- I think the concensus on summary item #12 is that maybe we can add the following points to the framework. Subnets longer than /64 are bad. Some devices don't support DHCPv6, therefore SLAAC is essential. Consumer oriented service providers of must allow customers to easily request and get prefixes shorter than /64 and preferably at no additional cost if we are to avoid having to subdivide /64s. Curtis --- Forwarded Message Message-Id: 201209230330.q8n3uix6047...@gateway1.orleans.occnc.com To: homenet@ietf.org cc: cur...@occnc.com Reply-To: cur...@occnc.com Subject: draft-ietf-homenet-arch-04 From: Curtis Villamizar cur...@occnc.com Date: Sat, 22 Sep 2012 23:30:44 -0400 Tim, Jari, Anders, Ole, Jason, I hope this is an OK time for comments on this draft. I just spent some time going through draft-ietf-homenet-arch-04 and I also took the time to look through all the RFCs and drafts that it references, even most of the expired ones. I edited in some diffs to the xml2rfc source. Most of the diffs should be self explanitory, though I'm sure some will not be without controversy on the WG list. I left in some XML comments where either I wanted to explain a change, or I would like to see some discussion on list. The xml file is at http://www.ietf.org/id/draft-ietf-homenet-arch-04.xml The diffs are below. Hopefully we can all read unified diffs of an xml file. I'll also summarize some major points here. 1. Must be capable of self configuring but should allow manual config. 2. A few citations could stand to be removed. Some drafts are expired and don't look like they were entirely completed. Some of the expired drafts look good but just managed to expire. 3. I am proposing that we drop the well known name as a means to discover the border(s). This seems to me like a real bad idea. 4. In Global addressability and elimination of NAT (false-)security concerns about losing NAT are cited but no advantage to global addressability is cited. I think that is an oversight but didn't add text here. (yet) 5. In a few places I've pointed out that firewalls (and NAT and anti-virus) provide very ineffective security and we should be very up front about saying so, though we can acknowledge that in the absense of reasonably secure home products, we can't get rid of them just yet. 6. Proposals for IPv6-only MUST provide some accommodations for legacy IPv4 only hosts or plain vanilla DS hosts. I called this IPv4 fallback on an otherwise IPv6 only network. I split the bullet on NAT64/DNS64 into two. a. As I had pointed out on the list, doing DNS64 at the CE (or a router) will break any IPv4 only host. The DNS64 translation should be done at the host. The NAT64 can be done at the CE (or any willing router). b. The DS-Lite B4 can be done on the host as long as DHCPv6 tells the host that an AFTR is availalbe. If the CE gets the FQDN of an AFTR as a DHCPv6 client on the WAN side it can pass that along to hosts as a server on the DHCPv6 homenet side. The DS-Lite B4 capable host can tunnel to the AFTR and not make a DHCPv4 request (operate v6only). The plain DS and IPv4-only hosts can make DHCPv4 requests. If V4 packets arrive at the CE, the CE can act as a B4 if the provider gave a AFTR FQDN in the WAN side DHCPv6. 7. If some topology can casue things to be broken, then what the homenet WG specified is broken. Added some text on pathelogical cases. The only true pathological case is a loop in a set of repeaters if a routing protocol is used and switches either detect cycles or use IEEE spanning tree or link state protocols. 8. Cascading NATs are common. Added text as to why. 9. Questioned why we mention VLANs. An unsophisticated home user is not likely to be playing with VLANs. 10. Should we get rid of physical standard references? I think so. 11. Modified bridge whenever possible text. Also Largest possible subnets section title changed to Largest practical subnets for reasons given in comments. 12. This is sure to be controversial. I pointed out that using subnets longer than /64 is OK as long as they are not leaked into global routing. Please read the text and changes before exploding on this topic. It may be necessary to subnet a /64 if that is all a provider will give you and you need subnets. It does work and it is no more unnatural than subnetting a class-A network would be in 1990. It means using DHCPv6 and not using RA prefixes for GUA (otherwise SLAAC implementations would likely try to use
Re: [homenet] draft-ietf-homenet-arch-04
In message 5061b322.1080...@gmail.com Brian E Carpenter writes: On 25/09/2012 02:01, Don Sturek wrote: Hi Curtis, I would expect most Wi-Fi AP manufacturers to support the same address assignment they do today (ie, manual assignment and DHCP). I would also expect as more IPv6 deployments happen that SLAAC will also be supported (and, yes, even for GUA). It MUST be supported according to RFC 6204 and 6204bis (and of course by all hosts, according to RFC 6434). Brian Brian, The I would expect wording is due to the very long lag between RFC mandates and the consumer products on retailer shelves that support those RFCs. Consumer products have yet to catch up to the RFCs in the 2xxx and 3xxx RFC range let alone anything in the 6xxx range. For example, the 4 port GbE and 2 Wifi channel AP I recently bought to run cerowrt supported little more than bridging IPv6 with the vendor firmware yet is advertised as having IPv6 support. That is not even the low end of consumer products. Curtis For the types of devices which will be added to Wi-Fi networks in the future (eg, headless devices like appliances, thermostats, etc.) that the preferred address assignment will be SLAAC and DHCPv6 (and, yes, I purposely did not remove SLAAC.) Don On 9/24/12 5:11 PM, Curtis Villamizar cur...@occnc.com wrote: In message 5060bdc7.6020...@freedesktop.org Jim Gettys writes: On 09/24/2012 03:17 PM, Don Sturek wrote: Hi Curtis, Here is the use case: 1) Customer has a legacy AP in their house 2) Customer brings home new devices supporting IPv6 (which are designed to communicate only with other IPv6 based devices in the home) 3) The only way these new devices can communicate is through address assignment using SLAAC and then some discovery method the two new devices support (without support from the AP). Here these devices are assuming bridging through the AP.. And since current legacy AP's all bridge, we win (even though we need to route in the future). Jim, The point was how do you get local IPv6 within the home with the legacy AP that does only IPv4 and just does bridging of IPv6. First of all you have no subnets. There is no CER to do DHCPv6. In this case you use link local or if everything has a MAC you can use ULA based on the MAC addressses. Placing a requirement that every customer who buys a new IPv6 device, intended to communicate only with other IPv6 devices in the home, will require a forklift upgrade of a deployed network in order to work will not be popular. Good point. But invalid. The use case Don gave would still work fine. Only GUA addresses are affected. I loathe DHCP (of any sort) *for basic address assignment, anyway* in the home environment. The loathing comes from the exquisite pain of suffering with a flaky home network for several months, before realising I had a rogue DHCP server somewhere on my network (from wireshark). I then had to take the mac address, figure out who may have manufactured some device from that information, and finally figured out the little VOIP ATA adaptor I had been given liked to do DHCP. It did DHCP on the *WAN side*? You didn't put the rest of your network behind the VOIP box on the LAN side I hope. This was by far the hardest debugging I've had to do in my home network in normal operation. This is well beyond normal home debugging capability of consumers. - Jim We all have plenty of crappy IPv4 product horror stories. My VOIP phone locked up now and then and I figured out that if the call lasted longer than the DHCPv4 lease, then it lost the least because it didn't try to renew it. Not only did the call drop, but the device locked up. The first solution was to reboot it now and then. The answer was to configure a fixed address. I was lucky to figure it out before my wife threw the phone through a window. For all I know a later firmware upgrade might have fixed it. VOIP might be more popular if VOIP phones under $600 worked reasonably well. Both nice stories, but both are DHCPv4 related and have nothing at all to do with SLAAC. Curtis Don On 9/24/12 11:49 AM, Curtis Villamizar cur...@occnc.com wrote: In message cc84f8f1.1a1c4%d.stu...@att.net Don Sturek writes: Hi Curtis, SLAAC not working is a major problem. Don Don, Why? This is an assertion without basis as far as I am concerned. Except CGA there is nothing that breaks without SLAAC. Joel brought up ILNP in private email, but I beleive ILNP can also work as the constraints in ILNP are in the ILNP identifier which is not the same as the interface address in ILNP for which there is no constraint. I have subnets running fine using a few /112 allocated from within a /64 with fixed addresses on rack mount hosts and desktops and DHCPv6
Re: [homenet] draft-ietf-homenet-arch-04
In message cc872d11.1a2ee%d.stu...@att.net Don Sturek writes: Hi Robert, One more point touched on in your note below: 1) Ideally, it would be great if a single authorizatative device existed in the home providing DHCPv6 server services (if supported) and prefix delegation. One challenge in the description below is having multiple routers on multiple subnets, each possibly acting as a DHCPv6 server within their own subnet and also providing their own ULA prefix. We certainly don't want to further confuse address assignment in a setting where IT support does not exist. Don We want things to just work witb no config. Link local on each subnet and a routing protocol works for any topology. ULA just allows summarization of subnets in the routing protocol, such that host routes are not needed (though not a big deal if host routes are used in a homenet). This would just work when using link local or ULA. How to subdivide a GUA prefix among the subnets is another issue. In principle, though I know of no proposals to do this yet, the set of GUA that are available from one of more routers with a provider link could be coordinated via the routing protocol (for example, using a new OSPF Opaque LSA). Curtis On 9/25/12 1:57 AM, Robert Cragie robert.cra...@gridmerge.com wrote: So let's tweak Curtis' sequence slightly: What every host does is: if it has no MAC: pick a random link local address else use the MAC to create a link local address run DAD to make sure no one else has same address send a RS if it gets RA use the RA prefix for SLAAC else time out and don't bother with SLAAC; can only use link local address then hopefully the host also does the following: send DHCPv6 client request if response it has yet another address to pick from if it got one using SLAAC else time out and get nothing from DHCPv6 This should work fine for legacy APs where everything is bridged underneath it. Where it gets interesting is in the case of cascaded subnets behind a router connected to an ISP, where one or more of those subnets may be a mesh network comprised of mesh routers and hosts. I am not quite sure how ULAs and DHCPv6 would work in this case as there are limitations as far as I can see (although I accept I probably have a bit more reading to do on the subject). Robert On 25/09/2012 5:45 AM, Curtis Villamizar wrote: In message cc866762.1a28f%d.stu...@att.net Don Sturek writes: Hi Curtis, I think the difficulty is each device cannot use the MAC to create a ULA address. Some authoritative device in the network (eg, the AP) must create the ULA prefix. If a ULA prefix is not present because the AP is a legacy device not capable of providing a ULA prefix, the STA devices must use link locals only. Don Don, You are right about there being nothing to generate the ULA prefix in your example. My mistake. But it doesn't change anything. If the AP is a dumb bridge and there is no router of any kind, then link local addresses are perfectly fine. There is only one subnet in that example, and ULA is not needed. That was the example you gave. Your example had no router just an old AP that acted as a bridge, therefore nothing to generate any sort of RA. If there is a router and no GUA prefix (which is not your example, but a useful example), then ULA can be used. The only RA that is seen is the RA providing a ULA prefix which the router can generate. I did say that the possibility of having to subdivide a /64 only exists for GUA. If a router exists which gets a GUA from a provider, and there are more subnets than the prefix length can support the two options are the ones listed below. (Search for --or--). Curtis On 9/24/12 6:52 PM, Curtis Villamizar cur...@occnc.com wrote: In message cc864fc3.1a27f%d.stu...@att.net Don Sturek writes: Hi Curtis, I would expect most Wi-Fi AP manufacturers to support the same address assignment they do today (ie, manual assignment and DHCP). I would also expect as more IPv6 deployments happen that SLAAC will also be supported (and, yes, even for GUA). For the types of devices which will be added to Wi-Fi networks in the future (eg, headless devices like appliances, thermostats, etc.) that the preferred address assignment will be SLAAC and DHCPv6 (and, yes, I purposely did not remove SLAAC.) Don Don, We seem to be talking past each other so let me again try to be clear. What every host does is: if it has no MAC: pick a random link local (not ULA) address else use the MAC to create a ULA address run DAD to make sure no one else has same address send a RS if it gets RA use the RA prefix for SLAAC else time out and don't bother with SLAAC then hopefully the host also does
Re: [homenet] draft-ietf-homenet-arch-04
In message 0abfee76-7737-41b7-96e1-8d90a0eff...@inf-net.nl Teco Boot writes: Op 25 sep. 2012, om 21:55 heeft Don Sturek het volgende geschreven: Hi Teco, The main requirement I see is that a home network with multiple ISP connections, multiple CERs and a shared subnet must support the ability to discover services within the entire site (home) despite having devices with differing ULA prefixes and GUA prefixes. How would you see discovery working in such a home network? It might be the right moment to come up with my earlier work on border router discovery. I have to update to incorporate the homenet-arch, and remove details for MANET/Autoconf. Intro highlights: http://tools.ietf.org/id/draft-boot-brdp-framework-00.txt If there is interest, I'll resubmit for Homenet. Teco Just looked at that draft. It solves one of the problems, having more than one GUA prefix. It does not solve another closely related problem, having more than one subnet behind the CER or border routers (BR101 and BR201 in your diagram) where there is no prior configuration. In your Figure 2: Scenario 2 all routers have the same set of addresses on each of their interfaces. This is not generally how subnets are laid out. Each interface on a router gets a different link local address. The /48 is usually split into a set of /64, one per subnet. In a managed network (enterprise, clueful soho, etc) the split of a /48 into 16 or less /64s today is done by configuration (configuration of prefixes on the routers or DHCP server and relays). Curtis Don On 9/25/12 12:34 PM, Teco Boot t...@inf-net.nl wrote: Op 25 sep. 2012, om 18:47 heeft Don Sturek het volgende geschreven: Sorry to jump in. Hi Robert, One more point touched on in your note below: 1) Ideally, it would be great if a single authorizatative device existed in the home providing DHCPv6 server services (if supported) and prefix delegation. I don't agree. When adding another gateway, to another ISP, I would like such to be independent form the existing gear. (3.2.2.2. B: Two ISPs, Two CERs, Shared subnet) One challenge in the description below is having multiple routers on multiple subnets, each possibly acting as a DHCPv6 server within their own subnet and also providing their own ULA prefix. When hosts get their addresses for each RA prefix, by using SLAAC and/or DHCPv6, what is the challenge? (protocol-wise, not current host behavior) When hosts get only one GUA, they will use only one link to one ISP (no translation). For multi-path, this needs an update. We certainly don't want to further confuse address assignment in a setting where IT support does not exist. Agreed, we need to improve address assignment. And routing based on destination source addresses. Teco Don On 9/25/12 1:57 AM, Robert Cragie robert.cra...@gridmerge.com wrote: So let's tweak Curtis' sequence slightly: What every host does is: if it has no MAC: pick a random link local address else use the MAC to create a link local address run DAD to make sure no one else has same address send a RS if it gets RA use the RA prefix for SLAAC else time out and don't bother with SLAAC; can only use link local address then hopefully the host also does the following: send DHCPv6 client request if response it has yet another address to pick from if it got one using SLAAC else time out and get nothing from DHCPv6 This should work fine for legacy APs where everything is bridged underneath it. Where it gets interesting is in the case of cascaded subnets behind a router connected to an ISP, where one or more of those subnets may be a mesh network comprised of mesh routers and hosts. I am not quite sure how ULAs and DHCPv6 would work in this case as there are limitations as far as I can see (although I accept I probably have a bit more reading to do on the subject). Robert On 25/09/2012 5:45 AM, Curtis Villamizar wrote: In message cc866762.1a28f%d.stu...@att.net Don Sturek writes: Hi Curtis, I think the difficulty is each device cannot use the MAC to create a ULA address. Some authoritative device in the network (eg, the AP) must create the ULA prefix. If a ULA prefix is not present because the AP is a legacy device not capable of providing a ULA prefix, the STA devices must use link locals only. Don Don, You are right about there being nothing to generate the ULA prefix in your example. My mistake. But it doesn't change anything. If the AP is a dumb bridge and there is no router of any kind, then link local addresses are perfectly fine. There is only one subnet in that example, and ULA is not needed. That was the example you gave. Your example had no router just an old AP that acted as a bridge
Re: [homenet] draft-ietf-homenet-arch-04
In message cc84f8f1.1a1c4%d.stu...@att.net Don Sturek writes: Hi Curtis, SLAAC not working is a major problem. Don Don, Why? This is an assertion without basis as far as I am concerned. Except CGA there is nothing that breaks without SLAAC. Joel brought up ILNP in private email, but I beleive ILNP can also work as the constraints in ILNP are in the ILNP identifier which is not the same as the interface address in ILNP for which there is no constraint. I have subnets running fine using a few /112 allocated from within a /64 with fixed addresses on rack mount hosts and desktops and DHCPv6 for dynamic allocations for laptops. It works fine. Link local addresses are all that is needed to get DHCPv6 to work. No host ever receives a RA since my routers won't give them one, so no host ever tries to generate an address using SLAAC. The only constraint is that any host connecting to my Ethernet or wireless must run a DHCP client and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 and DHCPv6 servers are available in every subnet except one GbE subnet in the rack and to a few hosts in my home office. So as far as I am concerned we have an assertion that no SLAAC is a problem and existance proof that it is not. Beside CGA and requiring that hosts run DHCPv6 if they want an IPv6 GUA, what can I not support on these /112 subnets? Curtis On 9/23/12 4:09 PM, Curtis Villamizar cur...@occnc.com wrote: In message 505e83f6.3030...@joelhalpern.com Joel M. Halpern writes: Since you invited flames... The argument on /64 as the longest prefix is not that it is magically unnatural. Rather, it is that there are a number of current and evolving protocols that depend upon that /64. The obvious example is that SLAAC does not work if subnets are longer than /64. The rules in this regard are written into approved RFCs. If homenet wants to change that, it really needs to go to 6man with a strong case. (for point-to-point inter-router links this was recently relaxed. At the same time, andy operator who insists on giving homes a /64 is being inappropriately restrictive. Homenet should say that, rather than trying to change the IPv6 architecture. Yours, Joel Joel, I don't consider your email a flame at all. Thanks for responding. SLAAC (which I am not at a fan of) won't work but DHCPv6 will so IMHO no loss. CGA also won't work but then again I've also never been a fan of security half measures. Yes anti-spoofing without prior exchange of a key is nice, but no reasonable authorization could be based on CGA without also exchanging some sort of key or cert and at that point the CGA as a public key is redundant. If SLAAC and CGA are the only things that break *and* providers do hand out prefixes that are too small, then /64 prefixes will have to be subdivided. So a question for you is what else if anything will break? I also understand that you are suggesting that this be taken to 6man. That is a good suggestion. Curtis On 9/22/2012 11:30 PM, Curtis Villamizar wrote: 12. This is sure to be controversial. I pointed out that using subnets longer than /64 is OK as long as they are not leaked into global routing. Please read the text and changes before exploding on this topic. It may be necessary to subnet a /64 if that is all a provider will give you and you need subnets. It does work and it is no more unnatural than subnetting a class-A network would be in 1990. It means using DHCPv6 and not using RA prefixes for GUA (otherwise SLAAC implementations would likely try to use the whole bottom 64). ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-arch-04
In message cc85fd9e.1a22f%d.stu...@att.net Don Sturek writes: Hi Curtis, Here is the use case: 1) Customer has a legacy AP in their house 2) Customer brings home new devices supporting IPv6 (which are designed to communicate only with other IPv6 based devices in the home) 3) The only way these new devices can communicate is through address assignment using SLAAC and then some discovery method the two new devices support (without support from the AP). Here these devices are assuming bridging through the AP.. Fine. Use link local addresses. SLAAC simply can't be used with the GUA prefix. SLAAC can be used with link local or ULA. Does this mean problem solved? Placing a requirement that every customer who buys a new IPv6 device, intended to communicate only with other IPv6 devices in the home, will require a forklift upgrade of a deployed network in order to work will not be popular. Don Maybe I wasn't clear in the summary paragraph. SLAAC can still be used but not for GUA. For the GUA DHCPv6 can be used and SLACC has to be avoided *if* the provider forced subdividing a /64 by refusing to allocate a prefix large enough (for example a fixed policy of /64 only for homes). I am not suggesting depricating SLAAC or not implementing it. All I am suggesting is that *if* you have a prefix that is too small, then you can sacrifice CGA but still support all the subnets you need by not providing an RA and providing DHCPv6 for the GUA prefixes that need to be longer than /64 within the homenet. If providers are all cooperative and are all willing to give out short enough prefixes, then the if in the prior paragraph never evaluates to true and the suggestion is a NOOP. I hope that was a bit more clear. btw- It seems to me that some respondents are reading the diffs to the draft and are replying only to the summary (or worse yet replying only to Joel's comment on summary point #12). Any reply is better than none, but please also read the diffs to the draft. Curtis On 9/24/12 11:49 AM, Curtis Villamizar cur...@occnc.com wrote: In message cc84f8f1.1a1c4%d.stu...@att.net Don Sturek writes: Hi Curtis, SLAAC not working is a major problem. Don Don, Why? This is an assertion without basis as far as I am concerned. Except CGA there is nothing that breaks without SLAAC. Joel brought up ILNP in private email, but I beleive ILNP can also work as the constraints in ILNP are in the ILNP identifier which is not the same as the interface address in ILNP for which there is no constraint. I have subnets running fine using a few /112 allocated from within a /64 with fixed addresses on rack mount hosts and desktops and DHCPv6 for dynamic allocations for laptops. It works fine. Link local addresses are all that is needed to get DHCPv6 to work. No host ever receives a RA since my routers won't give them one, so no host ever tries to generate an address using SLAAC. The only constraint is that any host connecting to my Ethernet or wireless must run a DHCP client and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 and DHCPv6 servers are available in every subnet except one GbE subnet in the rack and to a few hosts in my home office. So as far as I am concerned we have an assertion that no SLAAC is a problem and existance proof that it is not. Beside CGA and requiring that hosts run DHCPv6 if they want an IPv6 GUA, what can I not support on these /112 subnets? Curtis On 9/23/12 4:09 PM, Curtis Villamizar cur...@occnc.com wrote: In message 505e83f6.3030...@joelhalpern.com Joel M. Halpern writes: Since you invited flames... The argument on /64 as the longest prefix is not that it is magically unnatural. Rather, it is that there are a number of current and evolving protocols that depend upon that /64. The obvious example is that SLAAC does not work if subnets are longer than /64. The rules in this regard are written into approved RFCs. If homenet wants to change that, it really needs to go to 6man with a strong case. (for point-to-point inter-router links this was recently relaxed. At the same time, andy operator who insists on giving homes a /64 is being inappropriately restrictive. Homenet should say that, rather than trying to change the IPv6 architecture. Yours, Joel Joel, I don't consider your email a flame at all. Thanks for responding. SLAAC (which I am not at a fan of) won't work but DHCPv6 will so IMHO no loss. CGA also won't work but then again I've also never been a fan of security half measures. Yes anti-spoofing without prior exchange of a key is nice, but no reasonable authorization could be based on CGA without also exchanging some sort of key or cert and at that point the CGA as a public key is redundant. If SLAAC and CGA are the only things that break *and* providers do hand out
Re: [homenet] draft-ietf-homenet-arch-04
In message cc864fc3.1a27f%d.stu...@att.net Don Sturek writes: Hi Curtis, I would expect most Wi-Fi AP manufacturers to support the same address assignment they do today (ie, manual assignment and DHCP). I would also expect as more IPv6 deployments happen that SLAAC will also be supported (and, yes, even for GUA). For the types of devices which will be added to Wi-Fi networks in the future (eg, headless devices like appliances, thermostats, etc.) that the preferred address assignment will be SLAAC and DHCPv6 (and, yes, I purposely did not remove SLAAC.) Don Don, We seem to be talking past each other so let me again try to be clear. What every host does is: if it has no MAC: pick a random link local (not ULA) address else use the MAC to create a ULA address run DAD to make sure no one else has same address send a RS if it gets RA use the RA prefix for SLAAC else time out and don't bother with SLAAC then hopefully the host also does the following: send DHCPv6 client request if response it has yet another address to pick from if it got one using SLAAC else time out and get nothing from DHCPv6 Note: new extensions to DHCPv6 allow the host to tell DHCPv6 server the address that it already has (from SLAAC). If as in the case of your Wi-Fi with a bridging AP example, there is no router to give it an DHCPv6 the link local or ULA addresses are still there and still usable. There is also no router to give it an RA response so it has no SLAAC assigned address and no DHCPv6 assigned address. That is the end of your example. If there is a router then there is something that can hand out a RA or DHCPv6 response. In the case were there exists multiple subnets and the CER has been granted a /64 (or too few /64s to handle the number of subnets), then: it can use RA with /64 on some subnets and give them GUA addresses and some subnets have no access outside the homenet --or-- it can not use RA (and therefore prevent SLAAC from being used) and hand out DHCPv6 addresses and make use of prefixes longer than /64. This prevents the use of CGA but get connectivity to the entire homenet. If every consumer oriented provider is willing to allocate prefixes shorter than /64 on request to home users, then the above situation never occurs. If it does, my argument is that the second option above is better than the first. Curtis On 9/24/12 5:11 PM, Curtis Villamizar cur...@occnc.com wrote: In message 5060bdc7.6020...@freedesktop.org Jim Gettys writes: On 09/24/2012 03:17 PM, Don Sturek wrote: Hi Curtis, Here is the use case: 1) Customer has a legacy AP in their house 2) Customer brings home new devices supporting IPv6 (which are designed to communicate only with other IPv6 based devices in the home) 3) The only way these new devices can communicate is through address assignment using SLAAC and then some discovery method the two new devices support (without support from the AP). Here these devices are assuming bridging through the AP.. And since current legacy AP's all bridge, we win (even though we need to route in the future). Jim, The point was how do you get local IPv6 within the home with the legacy AP that does only IPv4 and just does bridging of IPv6. First of all you have no subnets. There is no CER to do DHCPv6. In this case you use link local or if everything has a MAC you can use ULA based on the MAC addressses. Placing a requirement that every customer who buys a new IPv6 device, intended to communicate only with other IPv6 devices in the home, will require a forklift upgrade of a deployed network in order to work will not be popular. Good point. But invalid. The use case Don gave would still work fine. Only GUA addresses are affected. I loathe DHCP (of any sort) *for basic address assignment, anyway* in the home environment. The loathing comes from the exquisite pain of suffering with a flaky home network for several months, before realising I had a rogue DHCP server somewhere on my network (from wireshark). I then had to take the mac address, figure out who may have manufactured some device from that information, and finally figured out the little VOIP ATA adaptor I had been given liked to do DHCP. It did DHCP on the *WAN side*? You didn't put the rest of your network behind the VOIP box on the LAN side I hope. This was by far the hardest debugging I've had to do in my home network in normal operation. This is well beyond normal home debugging capability of consumers. - Jim We all have plenty of crappy IPv4 product horror stories. My VOIP phone locked up now and then and I figured out that if the call lasted longer than the DHCPv4 lease, then it lost the least because it didn't try to renew it. Not only did the call drop, but the device locked up
Re: [homenet] draft-ietf-homenet-arch-04
In message cc866762.1a28f%d.stu...@att.net Don Sturek writes: Hi Curtis, I think the difficulty is each device cannot use the MAC to create a ULA address. Some authoritative device in the network (eg, the AP) must create the ULA prefix. If a ULA prefix is not present because the AP is a legacy device not capable of providing a ULA prefix, the STA devices must use link locals only. Don Don, You are right about there being nothing to generate the ULA prefix in your example. My mistake. But it doesn't change anything. If the AP is a dumb bridge and there is no router of any kind, then link local addresses are perfectly fine. There is only one subnet in that example, and ULA is not needed. That was the example you gave. Your example had no router just an old AP that acted as a bridge, therefore nothing to generate any sort of RA. If there is a router and no GUA prefix (which is not your example, but a useful example), then ULA can be used. The only RA that is seen is the RA providing a ULA prefix which the router can generate. I did say that the possibility of having to subdivide a /64 only exists for GUA. If a router exists which gets a GUA from a provider, and there are more subnets than the prefix length can support the two options are the ones listed below. (Search for --or--). Curtis On 9/24/12 6:52 PM, Curtis Villamizar cur...@occnc.com wrote: In message cc864fc3.1a27f%d.stu...@att.net Don Sturek writes: Hi Curtis, I would expect most Wi-Fi AP manufacturers to support the same address assignment they do today (ie, manual assignment and DHCP). I would also expect as more IPv6 deployments happen that SLAAC will also be supported (and, yes, even for GUA). For the types of devices which will be added to Wi-Fi networks in the future (eg, headless devices like appliances, thermostats, etc.) that the preferred address assignment will be SLAAC and DHCPv6 (and, yes, I purposely did not remove SLAAC.) Don Don, We seem to be talking past each other so let me again try to be clear. What every host does is: if it has no MAC: pick a random link local (not ULA) address else use the MAC to create a ULA address run DAD to make sure no one else has same address send a RS if it gets RA use the RA prefix for SLAAC else time out and don't bother with SLAAC then hopefully the host also does the following: send DHCPv6 client request if response it has yet another address to pick from if it got one using SLAAC else time out and get nothing from DHCPv6 Note: new extensions to DHCPv6 allow the host to tell DHCPv6 server the address that it already has (from SLAAC). If as in the case of your Wi-Fi with a bridging AP example, there is no router to give it an DHCPv6 the link local or ULA addresses are still there and still usable. There is also no router to give it an RA response so it has no SLAAC assigned address and no DHCPv6 assigned address. That is the end of your example. If there is a router then there is something that can hand out a RA or DHCPv6 response. In the case were there exists multiple subnets and the CER has been granted a /64 (or too few /64s to handle the number of subnets), then: it can use RA with /64 on some subnets and give them GUA addresses and some subnets have no access outside the homenet --or-- it can not use RA (and therefore prevent SLAAC from being used) and hand out DHCPv6 addresses and make use of prefixes longer than /64. This prevents the use of CGA but get connectivity to the entire homenet. If every consumer oriented provider is willing to allocate prefixes shorter than /64 on request to home users, then the above situation never occurs. If it does, my argument is that the second option above is better than the first. Curtis On 9/24/12 5:11 PM, Curtis Villamizar cur...@occnc.com wrote: In message 5060bdc7.6020...@freedesktop.org Jim Gettys writes: On 09/24/2012 03:17 PM, Don Sturek wrote: Hi Curtis, Here is the use case: 1) Customer has a legacy AP in their house 2) Customer brings home new devices supporting IPv6 (which are designed to communicate only with other IPv6 based devices in the home) 3) The only way these new devices can communicate is through address assignment using SLAAC and then some discovery method the two new devices support (without support from the AP). Here these devices are assuming bridging through the AP.. And since current legacy AP's all bridge, we win (even though we need to route in the future). Jim, The point was how do you get local IPv6 within the home with the legacy AP that does only IPv4 and just does bridging of IPv6. First of all you have no subnets. There is no CER to do DHCPv6. In this case you use link local
Re: [homenet] draft-ietf-homenet-arch-04
In message 505e83f6.3030...@joelhalpern.com Joel M. Halpern writes: Since you invited flames... The argument on /64 as the longest prefix is not that it is magically unnatural. Rather, it is that there are a number of current and evolving protocols that depend upon that /64. The obvious example is that SLAAC does not work if subnets are longer than /64. The rules in this regard are written into approved RFCs. If homenet wants to change that, it really needs to go to 6man with a strong case. (for point-to-point inter-router links this was recently relaxed. At the same time, andy operator who insists on giving homes a /64 is being inappropriately restrictive. Homenet should say that, rather than trying to change the IPv6 architecture. Yours, Joel Joel, I don't consider your email a flame at all. Thanks for responding. SLAAC (which I am not at a fan of) won't work but DHCPv6 will so IMHO no loss. CGA also won't work but then again I've also never been a fan of security half measures. Yes anti-spoofing without prior exchange of a key is nice, but no reasonable authorization could be based on CGA without also exchanging some sort of key or cert and at that point the CGA as a public key is redundant. If SLAAC and CGA are the only things that break *and* providers do hand out prefixes that are too small, then /64 prefixes will have to be subdivided. So a question for you is what else if anything will break? I also understand that you are suggesting that this be taken to 6man. That is a good suggestion. Curtis On 9/22/2012 11:30 PM, Curtis Villamizar wrote: 12. This is sure to be controversial. I pointed out that using subnets longer than /64 is OK as long as they are not leaked into global routing. Please read the text and changes before exploding on this topic. It may be necessary to subnet a /64 if that is all a provider will give you and you need subnets. It does work and it is no more unnatural than subnetting a class-A network would be in 1990. It means using DHCPv6 and not using RA prefixes for GUA (otherwise SLAAC implementations would likely try to use the whole bottom 64). ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] draft-ietf-homenet-arch-04
Tim, Jari, Anders, Ole, Jason, I hope this is an OK time for comments on this draft. I just spent some time going through draft-ietf-homenet-arch-04 and I also took the time to look through all the RFCs and drafts that it references, even most of the expired ones. I edited in some diffs to the xml2rfc source. Most of the diffs should be self explanitory, though I'm sure some will not be without controversy on the WG list. I left in some XML comments where either I wanted to explain a change, or I would like to see some discussion on list. The xml file is at http://www.ietf.org/id/draft-ietf-homenet-arch-04.xml The diffs are below. Hopefully we can all read unified diffs of an xml file. I'll also summarize some major points here. 1. Must be capable of self configuring but should allow manual config. 2. A few citations could stand to be removed. Some drafts are expired and don't look like they were entirely completed. Some of the expired drafts look good but just managed to expire. 3. I am proposing that we drop the well known name as a means to discover the border(s). This seems to me like a real bad idea. 4. In Global addressability and elimination of NAT (false-)security concerns about losing NAT are cited but no advantage to global addressability is cited. I think that is an oversight but didn't add text here. (yet) 5. In a few places I've pointed out that firewalls (and NAT and anti-virus) provide very ineffective security and we should be very up front about saying so, though we can acknowledge that in the absense of reasonably secure home products, we can't get rid of them just yet. 6. Proposals for IPv6-only MUST provide some accommodations for legacy IPv4 only hosts or plain vanilla DS hosts. I called this IPv4 fallback on an otherwise IPv6 only network. I split the bullet on NAT64/DNS64 into two. a. As I had pointed out on the list, doing DNS64 at the CE (or a router) will break any IPv4 only host. The DNS64 translation should be done at the host. The NAT64 can be done at the CE (or any willing router). b. The DS-Lite B4 can be done on the host as long as DHCPv6 tells the host that an AFTR is availalbe. If the CE gets the FQDN of an AFTR as a DHCPv6 client on the WAN side it can pass that along to hosts as a server on the DHCPv6 homenet side. The DS-Lite B4 capable host can tunnel to the AFTR and not make a DHCPv4 request (operate v6only). The plain DS and IPv4-only hosts can make DHCPv4 requests. If V4 packets arrive at the CE, the CE can act as a B4 if the provider gave a AFTR FQDN in the WAN side DHCPv6. 7. If some topology can casue things to be broken, then what the homenet WG specified is broken. Added some text on pathelogical cases. The only true pathological case is a loop in a set of repeaters if a routing protocol is used and switches either detect cycles or use IEEE spanning tree or link state protocols. 8. Cascading NATs are common. Added text as to why. 9. Questioned why we mention VLANs. An unsophisticated home user is not likely to be playing with VLANs. 10. Should we get rid of physical standard references? I think so. 11. Modified bridge whenever possible text. Also Largest possible subnets section title changed to Largest practical subnets for reasons given in comments. 12. This is sure to be controversial. I pointed out that using subnets longer than /64 is OK as long as they are not leaked into global routing. Please read the text and changes before exploding on this topic. It may be necessary to subnet a /64 if that is all a provider will give you and you need subnets. It does work and it is no more unnatural than subnetting a class-A network would be in 1990. It means using DHCPv6 and not using RA prefixes for GUA (otherwise SLAAC implementations would likely try to use the whole bottom 64). 13. There are a few minor wording changes, minor clarifications, etc. 14. There may be more fuss about confining interior routing within a border than needed. I added a paragraph that might help (or might not). 15. In the security section I added a subsection named Marginal Effectiveness of NAT and Firewalls. (btw- Firewall horror story at bar BOF on request.) 16. Added It has been suggested that Dynamic DNS could be made to operate in a zero-configuration mode using a locally significant root domain and with minimal configuration or using a DHCPv6 based (details to-be-defined) means of automated delegation populate a global DNS zone. Maybe a draft is needed on this but for now please discuss on list. 17. Suggest that any mechanism that is
Re: [homenet] Unicast DNS within the Homenet?
In message f5927c12-fe26-470f-82ae-f4387d30d...@fugue.com Ted Lemon writes: On Sep 12, 2012, at 2:41 AM, Ray Hunter v6...@globis.net wrote: Ted, respect your DHCP/DNS knowledge, but if we need a DHCP server anyway in Homenet, why don't we go for the classic enterprise set up that has run for years for IPv4, rather than trying to shoe horn locally assigned SLAAC addresses into global DNS? Two reasons. First, there's strong opposition to this, and so it will never happen, whether it is the right idea or not (I don't think it's particularly the right idea, although I'm not vehemently opposed to it either). Secondly, it precludes the use of CGA by hosts. Not using SLAAC does not preclude the use of CGA (RFC3971). The host can pick its own address with DHCP and use INFORM. It won't stop the host from using CGA or SEND (secure ND, RFC3972). Not that I think very highly of CGA as a security measure to start with but it could save a TCP RST on a TCP session running a protocol secured at the application layer and is lighter weight than IPSEC. That CGA was proposed in the first place is further proof that 128 bits in IPv6 addresses was pure folly. Unfortunately that decision dates all the way back to around 1995 and the huge addresses has been one reason IPv6 has been so slow to catch on. CGA tells us that the bottom 64 bits serves no purpose so we might as well use it for something else. The Flow ID field is another useless wart. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Unicast DNS within the Homenet?
In message 7e23e81a-9daa-45ac-a577-3b0574e1d...@fugue.com Ted Lemon writes: On Sep 12, 2012, at 9:02 PM, Mark Andrews ma...@isc.org wrote: My machines have names. Those names don't change as I move around the world. Random DHCP servers at coffee shops DO NOT have the ability to update the DNS entries for those names. They do have the authority to update the PTR records in in-addr.arpa and ip6.arpa namespaces. We're not talking about mobile IP herewe''re talking about naming in the homenet. The technology has existed for over a decade to do what you describe with DHCP and DDNS in IPv4, but AFAIK nobody uses it, for two reasons: one, I don't think it actually serves a real need, and two, it requires geek skills to set up, which most people don't have. But the second point is really a footnote to the first. DHCP and DDNS is used in enterprise and not for mobility, except to some extent mobility within the enterprise (laptops wandering to conference rooms). For anything that offers a service, meaning anything useful to connect to, DDNS is used so that if IT rearranges the wired ethernet, the server automagically has the same name but shows up somewhere else. In a past life IT tried to get me to do this with a CVS/SVN server but their DDNS didn't work enough times that I got them to go back to static entries. You can do things like direct SIP to a laptop with this and SIP URLs rather than (the far more common) B2BUA. There's a draft in the DHC working group for setting up the reverse zone... Did you mean: draft-lemon-dhc-dns-pd-01 Populating the DNS Reverse Tree for DHCP Delegated Prefixes Earlier in this thread you said: Ted, respect your DHCP/DNS knowledge, but if we need a DHCP server anyway in Homenet, why don't we go for the classic enterprise set up that has run for years for IPv4, rather than trying to shoe horn locally assigned SLAAC addresses i nto global DNS? Two reasons. First, there's strong opposition to this, and so it will never happen, whether it is the right idea or not (I don't think it's particularly the right idea, although I'm not vehemently opposed to it either). Secondly, it precludes the use of CGA by hosts. There is also draft-ietf-dhc-cga-config-dhcpv6-02 Configuring Cryptographically Generated Addresses (CGA) using DHCPv6 which is where I wondered why you said that CGA could not be used and maybe I missed something. In your opinion CGA cannot be used if ... SLAAC is not used? ... DHCPv6 is used? ... something else? Since you made that statement, exactly what did you means. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Unicast DNS within the Homenet?
In message 504f65c7.4010...@mtcc.com Michael Thomas writes: On 09/11/2012 09:01 AM, Ted Lemon wrote: There are a couple of options being pursued in the DHC working group; the DHCP address registration process would be an obvious mechanism for leveraging DHCP to populate the DNS. The idea here is that you do RA+SLAAC, or RA+CGA, and then you contact the DHCP server to tell it what address you allocated and what name you want associated with it, and to get any local network configuration information you might need. Maybe somebody can educated me, but isn't it a bit dangerous to use an auto-configured address as a way to contact a host? If I change out my ethernet hardware, for example, my auto-conf address would normally change too, right? However, of course this is new technology that isn't even standardized yet. I'd like it if homenet recommended implementing this, but I think another way of populating the DNS is through mDNSw hen a host publishes its name in mDNS, it's assumed to be valid as long as no conflicting registration has been made locally. I don't particularly love this method because mDNS doesn't have the same duplicate detection features that DHCP does through the DUID, but it wouldn't be _worse_ than plain mDNS, and would allow the DNS resolver to query a consistent FQDN tree for local names, so that it would work whether you were attached to the local wire or not. DHCP may be a solution but it ought not be the only solution, right? What if there's no relationship between my dns repository and the DHCP server? That is, suppose that Google hosted my DNS and thus wasn't actually on my home network. I suppose that a home router could work in concert by either working with its DHCP or listening to mdns chatter and then doing IXFR's to a name server. Is that what's being talked about? Mike Mike, suppose that Google hosted my DNS Create a zone names myhome.mydomain-at-google-ns and then you can have a zone for which dyn-DNS is authoritative. At that point the dynDNS server and DHCP server need not be the same host, just both under your control and able to use the dynDNS protocol to populate the dynDNS domain (the myhome subdomain in the prior example). Unless of course you can convince Google to honor dynDNS from your DHCP server (hint: no chance, create a subdomain if you want dynDNS). If Google is a secondary, not primary, then problem solved. Personally I have stayed away from mDNS, compiling out avahi (mDNS) or bonjour or anything similar in any port that offerred it. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Unicast DNS within the Homenet?
In message 20120911180743.gd15...@isc.org Evan Hunt writes: On Tue, Sep 11, 2012 at 12:37:30PM -0400, Ted Lemon wrote: No. Things change. All that's required to deal with this is that the underlying protocol support it. The DHCP DUID identification system does support this kind of change, as long as the actual device doesn't change. If the device changes, then when the registration expires, the name can be reclaimed. This does raise a point, though: Dynamic DNS doesn't have an expiration mechanism. Populating the DNS using mDNS is a good idea, I think, but it might be nice if we had some method of signaling the intended future disposation of a name. I'm thinking along the lines of a new rrtype, or maybe just a TXT record, that can indicate things like after time T, it's okay to delete this rrset, or if this name already exists with a different address, it's okay to replace the old one instead of adding to it. 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. It's probably my own fault for misconfiguring DHCP (I don't think it's doing the right thing in the on expiry block, and it hasn't been a high priority for me to fix it). But if we're going to be supplying DNS data from multiple sources -- DHCP, mDNS, maybe others -- then it might be a good idea to manage time limits on the demand side. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. Even, I've avoided that problem with the opposite approach. I have both fixed DNS and DHCP fixed entries for the laptops in my home. Anything else gets an address from the pool and no name except in the DHCP leases file. The only anything else is grandpa's laptop when he visits and my kids laptops when they are home, or other guests. I also get a stupid name based on serial number from one appliance that doesn't allow the name to be changed and also don't allow a fixed address to be configured. At least I know what it is and I can define a meaningful DNS name for it even if it won't take one. If my wife or I take a laptop elsewhere, to the library for example (or to IETF), then DHCP gives me a different address. No big deal but also no reconfig to go elsewhere. A bit deal for my wife, but then again she leaves her laptop at home all the time. I also have two mystery devices with a uid and no client-hostname. Not pingable. Hmm. :-( I would think that the dynDNS name would go away if the DHCP lease expired. Apparently not. I'd call that a bug. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Unicast DNS within the Homenet?
In message 47437c06-fb3d-41ab-adb9-01a409164...@nominet.org.uk Ray Bellis writes: 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? [*] The one obvious case is in-home web servers (i.e. CPE configuration) although a prior posting suggested that most people just use an IPv4 address (e.g. 192.168.1.1) rather than a DNS name for that. Many devices now support Bonjour for that. If it can be shown that Unicast DNS is only need for resolution of _external_ names then much of the discussion around _internal_ naming probably becomes moot. thanks, Ray [*] I'm specifically _not_ talking about normal recursive DNS for global DNS names. Ray, I've read the thread so far and I'm replying to the original message. The app that needs DNS is anything from outside or from a mobile device that requires access to the home without going through a cloud intermediary (usually not free). PC to PC SIP is one example, optionally with video. The most common intermediary is skype. There are also numerous SIP providers that essentially broker the initial connection for free (handle the SIP part, not the RTP part) and only charge if you connect to the PSTN where they are usually a SIP back to back UI connection and incur a fee from the PSTN. There is no reason why SIP URLs could not be used with IPv6. Admittedly, not a popular idea with the phone companies. For IPv4 today the cloud intermediary is a necessary evil due to both side being behind a NAT and having no means to get a DNS name for themselves. With IPv6 this can be solved. With IPv6 if we get it right you won't need to go through a third party to change your thermostat because you just found out that you are coming home early - you can directly address your thermostat by name (hopefully with reasonable authentication). At issue is whether the homenet WG is going to continue with PC world business as usual, which is lame discovery protocols that work only when there is only one subnet and are useless otherwise. One argument for multiple subnets is that bridging the GbE segment to the WiFi segment can swamp the WiFi segment. By routing between the two, active queue management (QoS) is easier and all of the segment broadcast and multicast on the GbE segment need not appear on the wireless. There are other motivations such as having an open guest wireless channel vs having a secure wireless channel, plus a wired segment. WiFi home routers able to support two channels are not uncommon today, though they are on the high end of home stuff (available on the shelves of you consumer and office supply places). It is better not to bridge the guest and secure segments together but rather to route between them. With IPv6 and the prospect of GUA for everything, the practice of hiding horribly insecure devices and protocols behind a firewall needs to disappear. It has proven unsafe over and over in enterprise of any size, where one compromise exposes the entire private side. If it is not DNS, it has to meet some requirements: 1. work over multiple subnets 2. tie into DNS if devices are to be accessed from elsewhere If it is DNS, it has to meet some requirement that DNS as practiced isn't very good at right now. 1. there needs to be a means of creating a namespace without going to a registry first (entirely local, but provider delegation would be better) 2. a usable interface is needed to assign names to devices (dyndns is almost adequate, setting host name on each device, but better would be to assign names centrally - configured dhcp entries) In either case where multiple routers are encountered, some means to resolve who is in charge of the name space is needed. Or we can continue with yet another lame half-baked solution de-jour for a single subnet home carrying forward the thinking of NATed PI addresses behind a firewall and have a different set of solutions for soho, small business, and up. Regarding some of the other comments. ... I see the point about the home with wireless audio and video components. There is only so much that can be done in a dorm or other high density housing (apartments) where having many WiFi APs crowd the channel space. Even where I live, where lots are 1.5-2.5 acres, I saw today 6 APs, three on channel 6, when I looked at my wife's laptop to see why it was having a bad day. This is why many dorms have wired Ethernet, and that tried to go all wireless and switched back. The campus library, the dorm lounges, etc still have wireless. Due to virus and worm problems MAC addresses need to be registered with campus IT before a student device is granted access. Only very public places like lounges and library have open wireless and are somewhat isolated (untrusted guest treatment). Of course students can still bring in wireless routers and NAT and
Re: [homenet] Tunnels to home
In message CAN2Hq07cserc=PHSLNpOf+K9sETLWmQQLPGm04796HY=dr0...@mail.gmail.com Richard Mortier writes: (apologies for the delay replying, have been catching up after a trip away.) On 15 August 2012 19:30, Curtis Villamizar cur...@occnc.com wrote: In message can2hq05sgfaoz36cmubgwkj+3yzmztyg2mxszb_rzytdo+s...@mail.gmail.com Richard Mortier writes: On 13 August 2012 20:04, Michael Richardson mcr+i...@sandelman.ca wrote: ... which would permit you to validate who I am, even though neither of have connectivity at the time.. I would cache my DNSSEC path, and of course, we each would already have the root DNSSEC key. (no different than how PKIX works...) I see signposts as being additional local trust anchors that can be used. yes, i think we would too :) You did trim out the example, where due to the trust, whitehouse.gov and billthecat.whitehouse.gov are all DNSSEC signed domains. I suppose that is why the smiley. the smiley is because (as anil's reply said), signpost uses dnssec precisely to get that trust. a smiley of agreement if you will. specifically: in the common case we'd envisage that each person would have at least one publicly visible signpost, probably hosted in the cloud (whether or not operated directly by them, or through some signpost-as-a-service provider) unless they have suitable local resources. ... and the difference between signed untrustworthy source of information and an unsigned untrustworthy is ... what? not sure what you mean here - could you expand? If the client does not have a configured trust anchor (for anything, DNSSEC included) and is getting one from a discovered source on the local network, then anything signed with it is inherently untrustworthy. The example (provided earlier on this thread) where whitehouse.gov and billthecat.whitehouse.gov are successfully spoofed *and* are DNSSEC signed is an example of a signed untrustworthy source. This is putting yet another service in the cloud that need not be there, though global DNS could be considered in the cloud as commonly practiced for the home user. What we are trying to accomplish is getting a local name service that is somehow authoritative for the local site, and optionally can be made global. Putting the mapping to the local printer in the cloud would break printing if the cloud were not accessible (hopefully temporarily) but for some devices, like home alarms, utility metering, the fridge, ... the kitchen sink, with low power wireless, the cloud might often not be there. we view both the local and global (ie., visible to the public, probably hosted in the cloud in most cases) as part of the same federated service. the local service (eg., at home) will continue to work if you are disconnected. the global service provides for access to the local services from outside that physical network. Does the client have a configured trust anchor for the global service? if either signpost or DNSSEC is using a trust anchor that is discovered dynamically, you have a huge security hole. -- Richard Mortier m...@cantab.net Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] naming, what's the problem?
In message 502fbeb4.40...@softathome.com Wouter Cloetens writes: DOn 18/08/12 05:05, Curtis Villamizar wrote: When a domain registrar is needed is only when the homenet needs or wants (maybe for ego reasons) a domain residing in a TLD (such as .com or .org) and would not accept a subdomain from the provider. For example the homenet user wants foo.com and would not accept something of the form foo.site.provider.com, which would be less permanet (the delegation is lost if switching providers). For security reasons documented in one of the drafts above, it should be disabled by default. A user-defined configuration could open the DNS port to the world, and allow additional domains. I think you missed the point. This is not a security issue. Yes, I got your point, but I'm adding an implication. The draft explains that this requires opening up the gateway's DNS port to the world, rather than only to the trusted DNS infrastructure of the provider. That has some security issues. There is the option for split horzon, but I don't think it should be the default. Having a GUA and not having a DNS name is not a *security* feature. More like paranoia IMHO. Security by obscurity has never worked. Also, only the provider can give you reverse DNS. The provider can delegate reverse DNS. That is a problem with uncooperative providers. Otherwise accurate rDNS is site local only, but at least it is accurate at the site. Whereas the provider-delegated domain can be a fully automatic feature, setting up a personal domain requires the user to do some work. Registering a domain (could be made simple, from a gateway's web UI), pointing a nameserver at his gateway (could be automated, DynDNS-style). It is only logical that a user should also have to disable the secure default source address restriction of DNS requests. If the user wants no work, the provider delegated subdomain can be reduced to zero work on the part of the customer, and a one time mechanical configuration on the part of the provider at the time that service is initiated (when new customer buys service for first time). Working with a registrar could be made simpler by the registrar, but most homes will never need a *vanity* domain in a TLD. Nonetheless, it is a perfectly valid use case; the IPv6 functional equivalent of widely used DynDNS in the IPv4 world today. And, of course, not every operator may implement the automated domain delegation. It seems that today, getting operators to do anything is difficult. Too bad we have so little competition in Internet service. :-( bfn, Wouter Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] naming, what's the problem?
In message 502e59e2.5040...@softathome.com Wouter Cloetens writes: On 08/08/12 20:48, Curtis Villamizar wrote: One solution, the one you are describing is where the CPE runs DHCP only and uses the dyndns protocol to make addresses available globally. Another solution is have the CPE run both DHCP and bind (or equiv) and run dyndns. The provider could delegate and secondary a subdomain of the provider with no need to contact a domain registry. Yes, that is exactly the 13 months old solution, described in these drafts: http://www.ietf.org/id/draft-mglt-homenet-naming-delegation-00.txt http://www.ietf.org/id/draft-mglt-homenet-front-end-naming-delegation-00.txt Thank you for pointing these out. I will take a look at them. When a domain registrar is needed is only when the homenet needs or wants (maybe for ego reasons) a domain residing in a TLD (such as .com or .org) and would not accept a subdomain from the provider. For example the homenet user wants foo.com and would not accept something of the form foo.site.provider.com, which would be less permanet (the delegation is lost if switching providers). For security reasons documented in one of the drafts above, it should be disabled by default. A user-defined configuration could open the DNS port to the world, and allow additional domains. I think you missed the point. This is not a security issue. The homenet user that wants foo.com needs to go to a domain registrar. The provider can only give out foo.site.provider.com but if this is for true home use and not business use, then that should be fine. The point is to be able to reach the home without typing in an IPv6 address. The same type of user happily accepts an email address of the form namestring@provider.com where namestring often has to contain numbers to keep it unique because all first names and most last names are already taken at the provider. It would be perfectly fine for the provider to offer namestring.site.provider.com as a domain delegation if namestring has already been assigned to the home as an account ID and email address. If the user want a domain name in a TLD, they need a domain name registrar. bfn, Wouter ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Tunnels to home
In message can2hq05sgfaoz36cmubgwkj+3yzmztyg2mxszb_rzytdo+s...@mail.gmail.com Richard Mortier writes: On 13 August 2012 20:04, Michael Richardson mcr+i...@sandelman.ca wrote: ... which would permit you to validate who I am, even though neither of have connectivity at the time.. I would cache my DNSSEC path, and of course, we each would already have the root DNSSEC key. (no different than how PKIX works...) I see signposts as being additional local trust anchors that can be used. yes, i think we would too :) You did trim out the example, where due to the trust, whitehouse.gov and billthecat.whitehouse.gov are all DNSSEC signed domains. I suppose that is why the smiley. specifically: in the common case we'd envisage that each person would have at least one publicly visible signpost, probably hosted in the cloud (whether or not operated directly by them, or through some signpost-as-a-service provider) unless they have suitable local resources. ... and the difference between signed untrustworthy source of information and an unsigned untrustworthy is ... what? This is putting yet another service in the cloud that need not be there, though global DNS could be considered in the cloud as commonly practiced for the home user. What we are trying to accomplish is getting a local name service that is somehow authoritative for the local site, and optionally can be made global. Putting the mapping to the local printer in the cloud would break printing if the cloud were not accessible (hopefully temporarily) but for some devices, like home alarms, utility metering, the fridge, ... the kitchen sink, with low power wireless, the cloud might often not be there. but we have certainly discussed supporting suitable state replication/caching among signpost instances so that any locally-connected collection of signpost-enabled clients can do all of this without recourse to the public internet (eg., for cases where you still want to be able to interconnect your own devices and you're travelling, or you're at home your broadband uplink has gone down). Please give us a good reason to reinvent the wheel. I don't see one. You need to say what DNS can't do, possibly with some extension. that signpost offers. Richard Mortier m...@cantab.net Regards, Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] LQDN (was tunnels as way to disambiguate .local)
In message 20120808185207.ga53...@isc.org Evan Hunt writes: Except, of course, that it's not a DN at all: it's not a domain name. Also not qualified, as long as we're quibbling. But I do think the distinction between FQDN and thing we're talking about is a useful one to have terminology for, and LQDN does get the job done even though it doesn't make proper acronymic sense; I suggest we continue using it here in the short term and plan on switching to a more precisely accurate term by the time we start producing RFC's. I don't have spare cycles to participate in the bikeshedding, but I'll be happy with anything that agrees with the definition previously proposed for LQDN. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. Even, With your definition, an enterprise with private DNS, (with nameservers that are not referenced by the root in any way) could also be considered to be not a DN. The LQDN is a domain of local scope, tied to a a local sitelocal. domain that does not exist or may be different outside the site local scope. An enterprise hidden domain is a domain of local scope tied to a local domainname that does exists outside and is known to be different outside of the site local scope. So the difference is: sitelocal may not exist everywhere and if it does it is different - an enterprise hidden domain is known to exist everywhere and is known to be different elsewhere. LQDN makes a distinction, separating it from FQDN. LQDN has local scope. FQDN has global scope. The distinction is useful. BTW- If you argued that mDNS was not a form of DNS, I would agree. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] LQDN (was tunnels as way to disambiguate .local)
In message 50236402.3020...@gmail.com
Brian E Carpenter writes:
On 08/08/2012 19:52, Evan Hunt wrote:
Except, of course, that it's not a DN at all: it's not a domain
name.
Also not qualified, as long as we're quibbling. But I do think the
distinction between FQDN and thing we're talking about is a useful one
to have terminology for, and LQDN does get the job done even though it
doesn't make proper acronymic sense; I suggest we continue using it here
in the short term and plan on switching to a more precisely accurate term
by the time we start producing RFC's.
I don't have spare cycles to participate in the bikeshedding, but I'll
be happy with anything that agrees with the definition previously
proposed for LQDN.
As far as I can see there are still two kinds of LQDN:
ALQDN - ambiguous, or potentially ambiguous, names (like printer.local)
ULQDN - unambiguous, or almost certainly unambiguous, names (like
printer.gibberish.sitelocal)
I will be unhappy if ALQDNs are allowed except as legacy.
Brian
Brian,
My prior suggestion is that we have both types of LQDN and not just
temporarily.
printer.{local|sitelocal} is an ALQDN
printer.gibberish.ulalocal is a ULQDN
printer.real-domain-name is a FQDN
For backward compatibility and to have a constant and easy to type
identifier, printer.{local|sitelocal} can be a CNAME where:
If an FQDN for printer exists:
ALQDN CNAME points to the FQDN
printer.{local|sitelocal} is a CNAME for printer.real-domain-name
rDNS points to the FQDN
in-add points to printer.real-domain-name
If an FQDN for print does not exist:
ALQDN CNAME points to the ULQDN
printer.{local|sitelocal} is a CNAME for printer.gibberish.ulalocal
rDNS points to the ULQDN
in-addr points to printer.gibberish.ulalocal
The application can detect that the mapping of the ALQDN has changed
in three ways. First the CNAME mapping has changed. Second the
address that is returned has changed. Third the rDNS has changed.
If a domain name is later acquired, then the application can detect
this on later use of the ALQDN in two ways. First the CNAME mapping
has changed. Second the rDNS has changed. Note that the final
forward mapping to an address has not changed in this case. If a
domain name appears, but the address remains the same, the mapping to
FQDN can silently replace the mapping to ULQDN (retaining the former).
If the final address associated with a ALQDN changes, then it may be
that the site local scope has changed. If so all ALQDN that map to
ULQDN can be retained but the user must be warned if specifying a
ALQDN. If the ALQDN had previously mapped to a ULQDN or FQDN that
mapped to a GUA, then the user can be given the option to try it. If
the ALQDN maps to a FQDN, the mapping can be verified. If the ALQDN
maps to a ULQDN, then the mapping cannot be verified but can be tried.
This is what I suggested before, just reworded and using your ALQDN vs
ULQDN distinction.
Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Tunnels to home
In message 50238a7a.9090...@gmail.com Brian E Carpenter writes: All this talk about tunnels and names made me think that people might be interested in the Signpost project, mainly based at the Computer Lab in Cambridge where I am currently a visitor. I think this project is a proof of concept for ideas being discussed here. http://conferences.sigcomm.org/sigcomm/2012/paper/sigcomm/p83.pdf (10MB file) http://conferences.npl.co.uk/satin/presentations/satin2012slides-Madhavapeddy.pdf Regards Brian Carpenter Remove NAT and the work has no purpose. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Tunnels to home
In message 11199.1344805...@obiwan.sandelman.ca Michael Richardson writes: Curtis =3D=3D Curtis Villamizar cur...@occnc.com writes: All this talk about tunnels and names made me think that people might be interested in the Signpost project, mainly based at the Computer Lab in Cambridge where I am currently a visitor. I think this project is a proof of concept for ideas being discussed here. =20 http://conferences.sigcomm.org/sigcomm/2012/paper/sigcomm/p83.pdf =20 (10MB file) http://conferences.npl.co.uk/satin/presentations/satin20= 12slides-Madhavapeddy.pdf =20 Regards Brian Carpenter Curtis Remove NAT and the work has no purpose. I don't quite agree. The external rendezvous is *FORCED* by NAT. The need for a rendezvous goes away with IPv6 end to end, assuming that security policies allow.=20=20 But, if we assume that end users should never type IPv6 addresses, then a rendezvous (which might now, be hosted by one or more devices at the home, rather than in the cloud!!!) is something that very much facilitates use by regular users. Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works=20 You are assuming that DNS would never be available to the home when you state that But, if we assume that end users should never type IPv6 addresses. This is technically solvable with IPv6, no NAT, and DNS. If some users end up typing IPv6 addresses for lack of DNS cooperation from their provider, they may consider switching providers. Even without cooperation from the provider, a device can have the resolver pointed at the home DNS server as a means of rendezvous if you want a rendezvous in the home. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] section 3.2.2.1 of homenet-arch
In message 502159c6.6060...@gmail.com Brian E Carpenter writes: On 07/08/2012 16:39, Curtis Villamizar wrote: In message 501a502d.30...@gmail.com Brian E Carpenter writes: On 01/08/2012 15:39, Curtis Villamizar wrote: In message 5018dd8a.2070...@gmail.com Brian E Carpenter writes: Excuse front posting, but... Today there is no DHCP help in avoiding the please reboot messages. Don't RECONFIGURE (DHCPv6) and FORCERENEW (DHCP) cover this, in theory? They are unicast, which is a scaling issue in enterprise networks but presumably not in homenets. Regards Brian These only force a renew before the lease expires. For the sometimes very long IPv6 leases, this is essential. For often relatively shorter IPv4 leases, it is nice but not quite as essential. The issue is not forcing the renew to occur earlier, it is the way in which a renew that changes the address is handled. Maybe its just implementations taking a shortcut, but I think in practice changing the IP address takes the interface down, kills all connections, including listens, and then brings it back up with a new address. Really? I can't test it in my current native-IPv6-deprived state, but it seems to me that Windows (at least) runs happily with multiple IPv6 addresses on one interface, and I can't imagine that changing one of them will kill the others. I have to admit I haven't studied the semantics of RECONFIGURE closely, though. The RFC 4192 model would look a bit sick if the interfaces get reset. Brian Brian, Aliases (more than one address on the same interface) Aliases, as you describe them, sound like a hack. I'd like to hear from Microsoft (for example) whether their support of multiple IPv6 addresses per interface is a hack or genuine. I don't care about IPv4, but the IPv6 model is very clear. You can't read the ND spec and imagine the arrival of a new address resetting sessions that use other addresses. Brian Brian, An alias is a second (or third or fourth) address bound to an interface. The name alias comes from the 2+ decades old ifconfig ... alias syntax. Every dual stack host uses aliases - it has an IPv4 address and more than one IPv6 address. This is also true of an IPv6 only interface with interface local, ULA, and GUA addresses. Every router with a GUA on the loopback (most likely every one deployed in a major provider) has a ::1 and the GUA as an alias on the loopback. Cisco added a loopback over 15 years ago just to support this. The purpose is to have a routable address that remains regardless of which forwarding cards fail or get pulled out. In modern implementations, once an alias is installed, it is no different from the original address. You can remove the original and keep the alias, which at one point you couldn't do. That is the most significant change to aliases in decades and has also been around a very long time. Aliases are critical to renumbering so that a transition period can exist while the renumbering process is in progress with no disruption at all to hosts as they are renumbered. has worked on every OS for a decade at least. Aliases have been around in BSD for more than two decades and existed before Microsoft had an IP stack in their product and before Linux existed. I would hope that by now *even Microsoft* has got it right. Curtis The issue is more what occurs when a lease is withdrawn (force to renew and won't renew) and another lease is provided with a different address. AFAIK most implementations take that interface down and bring it back up. They do not keep the old address as an alias for some period of time but put new connections on the new address. Curtis Its a bit like a reboot as implemented, except the user doesn't know its coming and therefore may have open TCP connections that break. BTW - It in this context is the existing delete old address, then add new address behavior of DHCP. What I've suggested is what to do on a renew that changes the address. Add an alias. Until the old address has no more connections or listens on the old address, keep the old address. Then remove the old address. If someone has an open connection, ssh for example, the old address could be in use indefinitely, but if the transition is weeks, then its unlikely to go beyond that. For example, if someone was using ssh to do a long compile on another machine, breaking the connection and killing the compile would be bad. There are certain to be plenty of other uses of long duration TCP connections that would have to be broken in this sort of transition, unless we can also extend TCP to negotiate a change to one side of the address pair. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] IPv6 aliases and renumbering (was Re: section 3.2.2.1 of homenet-arch)
In message 9600.1344364...@obiwan.sandelman.ca Michael Richardson writes: --=-=-= Content-Transfer-Encoding: quoted-printable Brian =3D=3D Brian E Carpenter brian.e.carpen...@gmail.com writes: Brian Aliases, as you describe them, sound like a hack. I'd like to Brian hear from Microsoft (for example) whether their support of Brian multiple IPv6 addresses per interface is a hack or genuine. I Brian don't care about IPv4, but the IPv6 model is very clear. You Brian can't read the ND spec and imagine the arrival of a new Brian address resetting sessions that use other addresses. On Linux and *BSD, (possibly including OSX, but I don't know, but I could do an experiment with my officemate), new addresses get added without an interface flap. Old addresses expire as they expire, no interface flap need occur. Linux does this all in the kernel, *BSD does it in rtsold. I can't speak of what happens with dhcpv6. Thanks. I just took a look at rtsold and rtadvd. If Linux kernel has a similar function (wrong place to put this IMHO, but ...), then perhaps in both rtsold and the Linux kernel in addition to an interface down and up event, a suspend and resume event should trigger a router solicitation. BTW- In BSD neighbor discovery is in the kernel and router solicitation and router advertisement are in userland. Note that in rfc4862 (SLAAC) we have: 5.5.4. Address Lifetime Expiry A preferred address becomes deprecated when its preferred lifetime expires. A deprecated address SHOULD continue to be used as a source address in existing communications, but SHOULD NOT be used to initiate new communications if an alternate (non-deprecated) address of sufficient scope can easily be used instead. The RFC indicates that an old address should remain preferred. It might be better if a newer address was preferred slightly more and could serve as a tie breaker. The choice of which one to use for new connections essentially depends upon the metrics on the route to that destination. Typically, for off-link destinations, it's the default route that matters. Where I think we see interface flaps is as a result of DHCPv4. If we lose connectivity to the DHCPv4, then the dhclient-daemon will reset the interface and start again. With wifi, this is often more frequent. I have had IPv6 connections survive such events, but not always. If you have a USB interface and pull it out, dhcpv4 is killed and does clean up and is restarted. In bsd the netif script is run with stop and start. Otherwise, if you just hop to another channel on the wireless, or unplug and plug the ethernet, the old address gets deleted (ifconfig ... -alias) and the new address added (ifconfig ... alias). Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works=20 It would be nice if for both IPv4 and IPv6 hopping to another channel on the wireless did not break old connections and did the right thing with new ones. Routers have a solution to any interface going down, but that solution is to put a routable address on the loopback. That works fine because the provider can carry the IPv4 /32 or IPv6 /128 routes within its borders, adding only one host route for each router, well worth it for the reliability gain. Within an enterprise, roaming around a building is supported by bridging all the hubs together at layer-2. This won't work for a home user roaming outside the home and down the block to a WiFi hotspot (in my case about 3-4 miles, so I'd have to rely in a lot of neighbors with open wifi). This roaming across subnets case could be made workable using a GUA on the loopback and forcing a tunnel back to the home when roaming outside the home. This could also be a feature supported by a wireless carrier, retaining an address on the loopback given at the tower where the connection started until that address was no longer needed. It would be up to IETF (maybe homenet) to describe how this should work (as described above is a candidate) and then up to home devices to include support for it. Being able to road at will without ever losing connections would be a valuable feature. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] LQDN (was tunnels as way to disambiguate .local)
Snipped most of this message. In message CABOxzu3qbzf=jQPnLg4QoNBMCe0v7i8QgAMMo_Mkk=6gvdk...@mail.gmail.com Kerry Lynn writes: I like to see us reserve FQDN for host names that are registered in the global DNS namespace, and use LQDN (or some other alternative) for host names in locally served zones. Any support for this? -K- Yes this is a good suggestion. Examples: printer3 is unqualified. printer3.local. in mDNS is a LQDN. printer3.sitelocal. (or any of the giberish.special-tld variants, including any based on ULA or alignment of the stars) in DNS is a LQDN. printer3.global-dns-domain. is a FQDN. Note that for both LQDN and FQDN above, a trailing dot exists. printer3.local.global-dns-domain. is and always was a valid FQDN even before mDNS existed. local is only reserved when used as a TLD. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
In message 5022557f.5050...@gmail.com Brian E Carpenter writes: On 07/08/2012 20:11, Michael Thomas wrote: On 08/07/2012 11:46 AM, Kerry Lynn wrote: On Mon, Aug 6, 2012 at 9:39 PM, Evan Hunt e...@isc.org wrote: Tunnels are okay, but to use them, but has to get the DNS search order and the DNS server list right, and that's walled garden territory. *If* we are going to turn each home into a walled garden, then let's be aware that we are doing that. I'm of the opinion that in a walled garden scenario, the tunnel endpoint may be the only resource that needs a global name / address. Just checking, but we all think that naming is a separate issue from reachability, right? It certainly is. But see http://tools.ietf.org/html/draft-carpenter-referral-ps especially section 4.2 FQDNs are not sufficient. Brian Brian, MIF may be trying to solve the problem the wrong way. Providing a mapping of DNS to loopback address has long been used (by routers) to provide a stable reachable address. The routing cost to reach that loopback interface (which can change many times for an active connection) is used to determine which physical interface gets used to reach the loopback. For example if one interface is connected to an ethernet which gets isolated due to a router failure, the other interface is used because routing tells us that one of them is unreachable. Multihoming of course pokes holes in the routing tables and causes some routing table bloat. This has always been a problem and IPv6 does nothing to improve the situation that existed in IPv4 two decades ago with a lot of small providers and large enterprises using dual provider multihoming. If we are concerned with hosts that have multiple interfaces both leading to parts of the homenet, that is easily solved. Multihomed homenets is a whole different problem, but solvable if redundancy is to the same provider. A conditional static route can be advertised within the provider, with these routes having limited scope (for example using BGP communities). If this practice were to become commonplace (I doubt it, no consumer provider has that sort of redundancy in the last mile), then the provider would have to limit the scope of these more specific routes to a small subset of their own topology. I get the impression that if NAT didn't exist, then draft-carpenter-referral-ps would server no purpose. Is this draft entirely motivated by problems caused by NAT? Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] naming, what's the problem?
In message 20120808133532.gb77...@mail.yitter.info Andrew Sullivan writes: On Wed, Aug 08, 2012 at 08:32:01AM -0400, David R Oran wrote: Yes, and a fairly hard one given the manual/administrative nature of domain registrations and the geek factor of secure dynamic DNS updates for all services to the global DNS. What is this geek factor whereof you speak? Once you have a name registered, registered your service with a service like dyn.com's DynDNS service, and told your gateway about it, everything else Just Works. I know this mostly because I know people who don't know anything about what they are doing, but who are able to navigate this far. What probably is true is at least the following: 1. Many people don't want to pay for (thereby use) their own name, and don't want to pay extra for a service like this. Dyn and (I believe) some of its competitors have free services of this sort, but they're somewhat restricted in what they can do. (Still, you can do this today when you buy shipping product from some vendors, without doing a single extra thing.) 2. Registering DNS names and somehow hooking them up to edge systems remains hard. DNSOP is actually investigating this problem, but maybe this WG ought to collaborate on that. 3. Split-horizon DNS isn't that reliable, and tends to leak. 4. Trying to make this work smoothly with .local addresses is probably a good way to cause confusion For what it's worth, after the discussion in Vancouver I went back to colleagues at Dyn to ask about previous work on standardizing what I might call the CPE-to-DNS-provider link, as I was pretty sure there'd been previous work. Indeed there had, and I'm attempting to dust it off. If we're serious about systems inside our target networks being somehow addressable from the global Internet, then it seems to me a mechanism to integrate easily to the global DNS without requiring major lock-in (or major upgrade of DHCP) is going to be something we'll have to tackle. Much as it would be great for Homenet to solve this problem and get a lot more functionality for users, this may be a bridge too far for the current work, which is focused on getting routing and naming INSIDE the home seamless and completely auto-configuring. If, on the other hand, we are in fact going to limit our scope to inside the home network (and what problem is it, exactly, that we have? My network can already do this, I think?) then of course the above is just needless extra work. I think the problem of disambiguating names of resources in the home has to be dealt with to prevent users whose devices are mobile from violating the principle of least astonishment. I don't think the ability to resolve names of home resources from anywhere on the Internet has to be solved in order to solve the disambiguation problem. I think that's a little optimistic. As soon as you have the problem, The name in context X is the same as in context Y and I want to be able to tell the difference when I cross context, you are already in Internet land. That's an interoperation problem, at least from the user's point of view. Best, A One solution, the one you are describing is where the CPE runs DHCP only and uses the dyndns protocol to make addresses available globally. Another solution is have the CPE run both DHCP and bind (or equiv) and run dyndns. The provider could delegate and secondary a subdomain of the provider with no need to contact a domain registry. When a domain registrar is needed is only when the homenet needs or wants (maybe for ego reasons) a domain residing in a TLD (such as .com or .org) and would not accept a subdomain from the provider. For example the homenet user wants foo.com and would not accept something of the form foo.site.provider.com, which would be less permanet (the delegation is lost if switching providers). Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] are FQDNs sufficient and if so for what?
The following is an excerpt from section 4.2. FQDNs are not sufficient in Brian's draft-carpenter-referral-ps-02.txt o In large networks, it is now quite common that the DNS administrator is out of touch with the applications user or administrator, and as a result, that the DNS is out of sync with reality. o DNS was never designed to accommodate mobile or roaming hosts, whose locator may change rapidly. o DNS has never been satisfactorily adapted to isolated, transiently-connected, or ad hoc networks. o It is no longer reasonable to assume that all addresses associated with a DNS name are bound to a single host. One result is that the DNS name might suffice for an initial connection, but a specific address is needed to rebind to the same peer, say, to recover from a broken connection. o It is no longer reasonable to assume that a DNS query will return all usable addresses for a host. o Hosts may be identified by a different URI per service: no unique URI scheme, meaning no single FQDN, will apply. The bottom line is I really don't see any serious problem with DNS. It doesn't solve everything but wasn't intended to and replacing it with a new mapping of names to address and other stuff won't change anything. The following is comments on each point individually. o In large networks, it is now quite common that the DNS administrator is out of touch with the applications user or administrator, and as a result, that the DNS is out of sync with reality. This is not a technical problem with DNS. Large DNS domains can be split into multiple subdomains. For example, universities have always delegated subdomains to departments that wanted them. It may be that a lot of enterprises that run Microsoft junk that maps into DNS are loath to use subdomains because it relinquishes control (turf issue) or because the Microsoft junk gets harder to administer when subdomains are in use. [That's the excuse I heard at the last corporation I was at - not sure if it is valid]. o DNS was never designed to accommodate mobile or roaming hosts, whose locator may change rapidly. A highly dynamic name resolution is not the answer to mobility. If so, then getting rid of the 15 minute minimal TTL would do it. But that would not solve the problem. The name would have to be updated exactly simultaneously to the new address being acquired if the old address is lost at the same time. The only reliable means of supporting unlimited mobility so far involves using a fixed address, and a fixed base station and a means of updating a tunnel from the base to the mobile device. o DNS has never been satisfactorily adapted to isolated, transiently-connected, or ad hoc networks. The suggestion to delegate to the home and provide secondary addresses the transiently-connected domain which wants to be primary. The same solutions to mobility apply to ad-hoc networks. The infrastructure is unnamed, but the nodes within it can be handled as mobile nodes, including any routers that are mobile. o It is no longer reasonable to assume that all addresses associated with a DNS name are bound to a single host. One result is that the DNS name might suffice for an initial connection, but a specific address is needed to rebind to the same peer, say, to recover from a broken connection. In the cases where this is true, the FQDN (www.content-provider.com) is intentionally mapped to a set of servers. Using HTTP 1.1 for example, there is no need to get the remaining chunks of a broken connection from the same server. Any of them should return the same result. In cases such as queries where results could vary, a redirect is done on initial query. Often this redirect is done anyway to point to a topologically closer server or a server with lower utilization. o It is no longer reasonable to assume that a DNS query will return all usable addresses for a host. Nor does it matter. Only one always reachable address is needed. It is about time that more than just routers started assigning a GUA to the loopback and putting that in the DNS such that no matter which interfaces were down or unreachable, the host was always reachable if at least one interface was up and reachable. o Hosts may be identified by a different URI per service: no unique URI scheme, meaning no single FQDN, will apply. CNAMEs are very helpful. I like keeping certain services as CNAME, such as www, krb, cvs, svn. Mail has its own redirection built in as MX records. If I want to ssh into the kerberos kdc I can use the CNAME kdc. It doesn't matter that this host may have other names. I can easily find out the FQDN that the CNAME points to. Curtis ___ homenet mailing list homenet@ietf.org
Re: [homenet] a modest proposal
In message alpine.deb.2.00.1208020755590.31...@uplift.swm.pp.se Mikael Abrahamsson writes: On Wed, 1 Aug 2012, Curtis Villamizar wrote: Same answer as one given on that thread. If a device can support IPv4, then use NAT4. If a device can only support IPv6, then the DNS64 belongs on the IPv6-only device. To that device all host return Am I interpreting you correctly in that you're saying that an IPv6 only device should have a built in resolver that does DNS64 in case of v6 only connectivity? I can see that this would work, but is that a generally accepted solution? On Android, this would mean that dnsmasq would need to gain DNS64 functionality (and also needs to be able to detect the NAT64 prefix somehow). -- Mikael Abrahamssonemail: swm...@swm.pp.se Re and also needs to be able to detect the NAT64 prefix somehow: Asking DNS to resolve nat64prefix might be a solution. It might find nat64prefix.sitelocal or nat64prefix.something-in-search-path. If so, then as long as it is on an IPv6 capable subnet (moot point if it is an IPv6 only host on a IPv4 only subnet) and can reach the nat64prefix, then it can reach the IPv4 world. This would work for mobile devices even without site local nat64 support as long as it knew where to find a remote nat64 gateway. OTOH preventing abuse of a remotely accessible nat64 gateway advertised in DNS would be a challenge. I don't think adding DNS64 to dnsmasq would be all that difficult. It is mostly translating A records into records unless I am missing something that is hard to do. Putting the DNS64 on the host would allow a mix of v6-only hosts and IPv4 only hosts and DS hosts on a DS network. On a v6-only subnet, v6 and DS hosts could operate with access to v4 only if they did DNS64. The option to put DNS64 in a gateway also exists, but would be a negative on a DS subnet if it were to accommodate a lone v6 only host (for example, a cellphone on the WiFi in a home or a hotspot running mostly v4 at this time). The problem with putting DNS64 at a gateway is that it breaks all of the v4 only devices (which are still plentiful). Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] section 3.2.2.1 of homenet-arch
In message 501a502d.30...@gmail.com Brian E Carpenter writes: On 01/08/2012 15:39, Curtis Villamizar wrote: In message 5018dd8a.2070...@gmail.com Brian E Carpenter writes: Excuse front posting, but... Today there is no DHCP help in avoiding the please reboot messages. Don't RECONFIGURE (DHCPv6) and FORCERENEW (DHCP) cover this, in theory? They are unicast, which is a scaling issue in enterprise networks but presumably not in homenets. Regards Brian These only force a renew before the lease expires. For the sometimes very long IPv6 leases, this is essential. For often relatively shorter IPv4 leases, it is nice but not quite as essential. The issue is not forcing the renew to occur earlier, it is the way in which a renew that changes the address is handled. Maybe its just implementations taking a shortcut, but I think in practice changing the IP address takes the interface down, kills all connections, including listens, and then brings it back up with a new address. Really? I can't test it in my current native-IPv6-deprived state, but it seems to me that Windows (at least) runs happily with multiple IPv6 addresses on one interface, and I can't imagine that changing one of them will kill the others. I have to admit I haven't studied the semantics of RECONFIGURE closely, though. The RFC 4192 model would look a bit sick if the interfaces get reset. Brian Brian, Aliases (more than one address on the same interface) has worked on every OS for a decade at least. The issue is more what occurs when a lease is withdrawn (force to renew and won't renew) and another lease is provided with a different address. AFAIK most implementations take that interface down and bring it back up. They do not keep the old address as an alias for some period of time but put new connections on the new address. Curtis Its a bit like a reboot as implemented, except the user doesn't know its coming and therefore may have open TCP connections that break. What I've suggested is what to do on a renew that changes the address. Add an alias. Until the old address has no more connections or listens on the old address, keep the old address. Then remove the old address. If someone has an open connection, ssh for example, the old address could be in use indefinitely, but if the transition is weeks, then its unlikely to go beyond that. For example, if someone was using ssh to do a long compile on another machine, breaking the connection and killing the compile would be bad. There are certain to be plenty of other uses of long duration TCP connections that would have to be broken in this sort of transition, unless we can also extend TCP to negotiate a change to one side of the address pair. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] a modest proposal
In message 501a568c.9040...@gmail.com Brian E Carpenter writes: On 02/08/2012 06:58, Mikael Abrahamsson wrote: On Wed, 1 Aug 2012, Curtis Villamizar wrote: Same answer as one given on that thread. If a device can support IPv4, then use NAT4. If a device can only support IPv6, then the DNS64 belongs on the IPv6-only device. To that device all host return Am I interpreting you correctly in that you're saying that an IPv6 only device should have a built in resolver that does DNS64 in case of v6 only connectivity? I can see that this would work, but is that a generally accepted solution? On Android, this would mean that dnsmasq would need to gain DNS64 functionality (and also needs to be able to detect the NAT64 prefix somehow). That is one of the models discussed in BEHAVE, of course, and it deals neatly with the DNSSEC conundrum for DNS64. But the normal model is the one that Curtis doesn't like. NAT64/DNS64 plays better when the client network is truly IPv6-only; with mixed hosts, you really need to provision dual stack hosts with a normal DNS server, and the IPv6-only hosts with a DNS64. Brian Brian, What you suggest might be accomplished by having DHCP4 return a different nameserver than DHCP6. At the very least the same nameserver (same copy of bind or whatever on a DS machine) could respond differently if the private side query arrives via IPv4 than if it arrives via IPv6. Worst case is DS machines make use of NAT64 when they could have used IPv4. [aside: Bind has views, but I don't know if the view support would allow this. It seems like it would. It would be nice if this were doable today with no changes. ie: existance proof] Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
. It also completely avoids trying to synch mDNS with DNS, which I think you'll agree is likely to be very difficult. Curtis Villamizar mailto:cur...@occnc.com 4 August 2012 22:06 With all due respect, any suggestion to use the ULA in a domain name produces either a domain that is unique to one host or a domain that is every bit as global as sitelocal, depending on whether by stating ULA prefix you mean the local ULA or the well-known global ULA prefix. In rfc4193: Local IPv6 unicast addresses have the following characteristics: - Globally unique prefix (with high probability of uniqueness). - Well-known prefix to allow for easy filtering at site boundaries. [...] If you mean the first (the local ULA prefix), then the domain is unique to one host. My computer could never find my fridge using the hostname fridge unless it knew every ULA on the local network and created an entry in the dns search path. Very long entries in the dns search path are a very bad thing (tm). If you means the second (the assigned prefix under which all ULA fall) then the domain is common to all hosts in the universe that generate a ULA address. The only difference is it is host.somethingveryobscure.sitelocal. Curtis In message 501965d4.1040...@globis.net ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
In message 8857.1343917...@obiwan.sandelman.ca Michael Richardson writes: Brian =- Brian E Carpenter brian.e.carpen...@gmail.com writes: Brian Correct, but the name is unambiguous, which IMHO is a MUST Brian property for anything that looks like an FQDN. We have to Brian live with .local but it should be just a nasty memory like Brian 10.0.0.0/8 fifty years from now. Brian I would suggest instructing IANA to reserve all TLD strings Brian that start with local and using something like Brian .local-fd952a92a67d to name the homenet domain. It's only a Brian convenience to use a ULA prefix; it's simply a unique string Brian that the CPE needs to generate anyway, but it has no Brian significance beyond that. huh, you want to do it that way? Why not fd952a92a67d.local? I'm asking for clarification, not disagreeing. Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works I'd prefer mDNS returns a mapping of printer3.local to a CNAME printer3.fqdn and DNS returns a mapping of printer3.sitelocal (or localsite if you prefer) to CNAME printer3.fqdn. In both cases, if there is a subdomain delegated by the provider, then fqdn is that subdomain, and if no subdomain has been delegated, then the fqdn is of the form ula.local (ie: fd952a92a67d.local in your example). An application can (though none today do, cups for example could be changed) obtain the query results using the partial domain name (ie: printer3) and gethostbyname2 to get an address and then use gethostbyaddr to do an rDNS lookup to get the FQDN if printer3.sitelocal was first in the DNS search path. If the mapping from printer3.sitelocal were to change, the user could be given a choice to use the new printer3.sitelocal or use the old one through the FQDN. Multiple mappings of printer3.sitelocal could be retained, such that printer3 yielded a list each time a request was made to print using this unqualified name. Of course that would mean rDNS would have to work. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
With all due respect, any suggestion to use the ULA in a domain name produces either a domain that is unique to one host or a domain that is every bit as global as sitelocal, depending on whether by stating ULA prefix you mean the local ULA or the well-known global ULA prefix. In rfc4193: Local IPv6 unicast addresses have the following characteristics: - Globally unique prefix (with high probability of uniqueness). - Well-known prefix to allow for easy filtering at site boundaries. [...] If you mean the first (the local ULA prefix), then the domain is unique to one host. My computer could never find my fridge using the hostname fridge unless it knew every ULA on the local network and created an entry in the dns search path. Very long entries in the dns search path are a very bad thing (tm). If you means the second (the assigned prefix under which all ULA fall) then the domain is common to all hosts in the universe that generate a ULA address. The only difference is it is host.somethingveryobscure.sitelocal. Curtis In message 501965d4.1040...@globis.net Ray Hunter writes: Isn't it possible to combine the two ideas of sitelocal. with pseudo-domains generated from ULA to give a usable solution? e.g. fridge.pseudo-ula-domain.sitelocal. Don't you then avoid the evilness of identifier overloading (my fridge versus your fridge) and potential problems with clashing TLD's? e.g. someone registering a bunch of pseudo-ula-domain. TLD records as their company brand for manual administration. How else are homenet devices going to know not to bother the root servers with fridge.pseudo-ula-domain. NS queries given that TLD's are now basically a free for all? Wouldn't it also potentially give a unique anchor point for storing DNSSEC zone signing with an implicit sitelocal. trust anchor? regards, RayH Brian E Carpenter wrote: Synthesise a pseudo-TLD from the ULA prefix. Brian Brian E Carpenter wrote: On 01/08/2012 05:48, Curtis Villamizar wrote: ... fridge.sitelocal. is a FQDN with site local scope. And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil. IMHO we shouldn't be discussing how to make it work less badly; we should be discussing how to avoid it entirely. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] section 3.2.2.1 of homenet-arch
In message 5018dd8a.2070...@gmail.com Brian E Carpenter writes: Excuse front posting, but... Today there is no DHCP help in avoiding the please reboot messages. Don't RECONFIGURE (DHCPv6) and FORCERENEW (DHCP) cover this, in theory? They are unicast, which is a scaling issue in enterprise networks but presumably not in homenets. Regards Brian These only force a renew before the lease expires. For the sometimes very long IPv6 leases, this is essential. For often relatively shorter IPv4 leases, it is nice but not quite as essential. The issue is not forcing the renew to occur earlier, it is the way in which a renew that changes the address is handled. Maybe its just implementations taking a shortcut, but I think in practice changing the IP address takes the interface down, kills all connections, including listens, and then brings it back up with a new address. Its a bit like a reboot as implemented, except the user doesn't know its coming and therefore may have open TCP connections that break. What I've suggested is what to do on a renew that changes the address. Add an alias. Until the old address has no more connections or listens on the old address, keep the old address. Then remove the old address. If someone has an open connection, ssh for example, the old address could be in use indefinitely, but if the transition is weeks, then its unlikely to go beyond that. For example, if someone was using ssh to do a long compile on another machine, breaking the connection and killing the compile would be bad. There are certain to be plenty of other uses of long duration TCP connections that would have to be broken in this sort of transition, unless we can also extend TCP to negotiate a change to one side of the address pair. Curtis On 01/08/2012 04:33, Curtis Villamizar wrote: In message 50181a1c.5050...@gmail.com Brian E Carpenter writes: On 31/07/2012 17:59, Michael Richardson wrote: Brian == Brian E Carpenter Brian writes: I'm also surprised that we think we have to cope with flash renumbering as a regular event, rather than a service-interrupting, ISP truck roll catastrophy. Brian But every time you reboot your antiquated v4-only CPE Brian and/or the antiquated Brian v4-only PCs behind it, the PCs all get new IP addresses, Brian which may or Brian may not be the same as the previous time. There's nothing Brian new in flash Brian renumbering for homenets. Not handling this would be a step Brian backwards. Well... 1) sure, but the *customer* does this, not the ISP. 2) the clients do have DHCP leases, and if they ask to renew their previous IP, it usually gets honored. It doesn't matter whether it's the user or the ISP that triggers a change, does it? The point is, users don't care about this, except if they reach their shiny new wireless printer via its IP static address. There are definitely parts of draft-ietf-6renum-static-problem that apply here. Brian Brian, Enterprise renumbering and homenet renumbering are generally quite different. Most homehets have short uptimes. Most enterprises have very long uptimes. (insert favorite Microsoft reliability joke here). If a renumbering is done right, there is an time when both the old and new numbers are in use. As in ifconfig intf inet6 newaddr ... alias in the *ix world. During that transition time any use of DHCP will hand out the new address. Then comes a time when the leases refuse to be renewed. Then the old addresses go away. This can be day, weeks, or longer depending on the size of the transition. During that time a lot of please reboot at least once ... messages get sent. Today there is no DHCP help in avoiding the please reboot messages. It should be possible for a DHCP client (ISC guys, are you out there?) to do the following if a lease can't be renew and a new address is provided: 1. Add the new address using an ifconfig intf ... alias equivalent. 2. Check (using netstat -an equivalent) for use of the old address. Don't delete the old address if a socket still exists. 3. Periodically repeat step 2 until there is no connection using the old address. 4. Delete the old address using the equivalent of ifconfig intf ... -alias. This would work for all client side connects that either were done before the end of the transition period. For home nets this covers 99.something percent of the sites with no user intervention or reboot. This requires no protocol change, just better coding in the DHCP client software. What this does not cover is a service that is listenning on a well known port. This is rare among home nets (except for homes of readers of IETF lists) but very common among enterprises. Many points made about license servers, etc
Re: [homenet] a modest proposal
In message 5018df5e.6040...@gmail.com Brian E Carpenter writes: On 31/07/2012 22:45, Curtis Villamizar wrote: In message 5017d819.9030...@mtcc.com Michael Thomas writes: On 07/31/2012 01:00 AM, Brian E Carpenter wrote: On 31/07/2012 01:20, Michael Thomas wrote: On 07/30/2012 05:10 PM, Curtis Villamizar wrote: If you see some advantage that solves the IPv4 address depletion (a big point of the transition to IPv6 exercise), then I've missed it. If so, please point out what I missed. No, not at all and not the point. I'm just of the mind that if we believe that v6 is really, really ready to go there shouldn't be any problem in substituting rfc1918 v4 space with v6 ULA space. If that modest change leads to trouble... Well, it surely requires a DNS64 resolver in the CPE too. Having embedded DNS functionality in the CPE is sort of a newish requirement, yes? If we think that's inevitable for real homenets, maybe this is a means of moving the ball forward? Mike This requirement is Not at all new. Most low endish CPE get a single IPv4 address from the provider, do NAT, offer PI addresses on the home side, offer themselves as DNS resolvers on the home side. Act as a DNS cache using the nameserver(s) offerred by the service provider as forwarders. Most home users get the CPE from the provider and the providers like having a resolver in the CPE so today this is a business requirement, not an IETF requirement. That's true. My point was that the CPE resolver will have to be upgraded to support DNS64 for, and *only* for, IPv6-only hosts. How it knows which hosts are IPv6-only is another mystery. Brian Brian, I was responding to the question: Having embedded DNS functionality in the CPE is sort of a newish requirement, yes? Having DNS in the CPE is not a new requirement (at least in practice). Extending the requirement to include DNS64 is new. How it knows which hosts are IPv6-only is another mystery. I'm not if favor of using IPv4 in IPv6 and then having a NAT to turn the IPv6 addresses into a single IPv4. I agree with a prior comment that this is complexity added with no significant gain. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] section 3.2.2.1 of homenet-arch
In message 20120801082004.25b4c2329...@drugs.dv.isc.org Mark Andrews writes: In message 201208010333.q713xjub089...@gateway.ipv6.occnc.com, Curtis Villamizar writes: In message 50181a1c.5050...@gmail.com Brian E Carpenter writes: On 31/07/2012 17:59, Michael Richardson wrote: Brian == Brian E Carpenter Brian writes: I'm also surprised that we think we have to cope with flash renumbering as a regular event, rather than a service-interrupting, ISP truck roll catastrophy. Brian But every time you reboot your antiquated v4-only CPE Brian and/or the antiquated Brian v4-only PCs behind it, the PCs all get new IP addresses, Brian which may or Brian may not be the same as the previous time. There's nothing Brian new in flash Brian renumbering for homenets. Not handling this would be a step Brian backwards. Well... 1) sure, but the *customer* does this, not the ISP. 2) the clients do have DHCP leases, and if they ask to renew their previous IP, it usually gets honored. It doesn't matter whether it's the user or the ISP that triggers a change, does it? The point is, users don't care about this, except if they reach their shiny new wireless printer via its IP static address. There are definitely parts of draft-ietf-6renum-static-problem that apply here. Brian Brian, Enterprise renumbering and homenet renumbering are generally quite different. Most homehets have short uptimes. Most enterprises have very long uptimes. (insert favorite Microsoft reliability joke here). Define short? There are plenty of homes with equipment that isn't powered down every day and that has been up for months. As long as the equipment is idle, an attempted renew on the DHCP lease that fails won't hurt unless it causes something to hang. Microsoft has trained users to be used to power cycling things for no apparent reason. I don't know about other but I maintain ssh connections for weeks from home to the main office at work. I've been know to do that. For long compiles I've learned to use nohup and keep a log file that I can check on now and then. If a renumbering is done right, there is an time when both the old and new numbers are in use. As in ifconfig intf inet6 newaddr ... alias in the *ix world. During that transition time any use of DHCP will hand out the new address. Then comes a time when the leases refuse to be renewed. Then the old addresses go away. This can be day, weeks, or longer depending on the size of the transition. During that time a lot of please reboot at least once ... messages get sent. What's the dhcp stuff in the home? RA's work fine here. What is needed is a way to signal in the DNS to only use a deprecated address as a last resort measure. Named to address and address to name mappings need to exist until after the address has ceased being used. Below is what the CPE and host need to do. The provider also needs to keep around the old rDNS until the old address is no longer in use. The provider needs to 1) grant new leases from the new number space, 2) request that users force a renew themselves in case there would be any disruption, 3) allow time for users to force a renew, 4) force a renew and refuse torenew the old leases, granting new ones (may be disruptive to some), 4) allow more time, then completely get rid of the old address space. Today there is no DHCP help in avoiding the please reboot messages. It should be possible for a DHCP client (ISC guys, are you out there?) to do the following if a lease can't be renew and a new address is provided: 1. Add the new address using an ifconfig intf ... alias equivalent. 2. Check (using netstat -an equivalent) for use of the old address. Don't delete the old address if a socket still exists. 3. Periodically repeat step 2 until there is no connection using the old address. 4. Delete the old address using the equivalent of ifconfig intf ... -alias. Actually you should be asking the OS vendors / distro maintainers to do this and send fixes to ISC. This is all done in shell scripts that are highly customised to the client platform. There isn't one linux script that works for all linux distros. This also doesn't work for many udp based services. You are right. There are other retained IP addresses. For example, a DNS secondary might try to renew a lease based on the old address until the primary name server DNS entry TTL expires. Perhaps a minimum time in which there is no use of the old address is necessary. Note that netstat -in on *ix reports statistics per alias so it is possible to detect when a specific address has gone idle for a long time, but there is no guarentee that it won't ever be used again
Re: [homenet] a modest proposal
In message alpine.deb.2.00.1208011010560.31...@uplift.swm.pp.se Mikael Abrahamsson writes: On Wed, 1 Aug 2012, Brian E Carpenter wrote: That's true. My point was that the CPE resolver will have to be upgraded to support DNS64 for, and *only* for, IPv6-only hosts. How it knows which hosts are IPv6-only is another mystery. Indeed, I started a thread about this on v6ops the other day: http://www.ietf.org/mail-archive/web/v6ops/current/msg13581.html Seems there is no solution to this problem and I'm seem to be having trouble getting traction there that this might actually be a real problem that needs solving. Same answer as one given on that thread. If a device can support IPv4, then use NAT4. If a device can only support IPv6, then the DNS64 belongs on the IPv6-only device. To that device all host return records, since the A records are translated into ipv4-in-ipv6 space. The CPE should be dual stack and be capable of both NAT4 and NAT64 translations to allow reachability into the IPv4 world. This is simple. As pointed out on the thread, a patch has already been submitted to android and some 3gpp phone already do DNS64. If the CPE doesn't do NAT64, the packet will wander along some route, most likely the default route, until it either hits a NAT64 or runs into a black hole. Propogating DNS64 translated address can cause severe problems and therefore should never leak outside the single IPv6 only host that needs it to get to IPv4 addresses. DNS64 and NAT64 already exist for BSD and Linux (bind and pf for BSD, bind and linuxnat64 for linux). Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
In message 50193cab.5070...@gmail.com Brian E Carpenter writes: Synthesise a pseudo-TLD from the ULA prefix. Brian If the whole ULA is used, then the scope is single host. If the ULA prefix is used, then the scope is all reachable ULA which is the same as sitelocal but with an obscure name. Curtis On 01/08/2012 15:17, Curtis Villamizar wrote: In message 5018d80c.90...@gmail.com Brian E Carpenter writes: On 01/08/2012 05:48, Curtis Villamizar wrote: ... fridge.sitelocal. is a FQDN with site local scope. And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil. IMHO we shouldn't be discussing how to make it work less badly; we should be discussing how to avoid it entirely. Brian Brian, Not being connected to the Internet and not having any configuration at all might also be intrinsically evil, but that's the situation when a consumer takes some gadget out of the box. What we are trying to accomplish with the sitelocal is a way to name things on a local network that have no domain name assigned through a registry and have not had a domain name assigned as part of some subdomain of the provider. Even if the homenet WG was extremely thoroughthe gadget did 100% of what we specify and implemented everything perfectly, we can't control the user who almost never has a domain name of their own or the ISP that can't be bothered delegating some subdomain of theirs to a customer. The customer then has no global domain to hang names off of and has no choice but to not use DNS or make use of a sitelocal domain with site local scope. So sitelocal is inherently needed, either during a transition (until the uplink comes up at least for the first time and a domain name is learned) or permanently (if no domain name ever gets delegated to the residential customer site). Curtis ps - Yes - it is inherently evil. So is not delegating rDNS IMHO. But we can't control those MSO and ILEC residential ISPs. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
In message 17002.1343839...@obiwan.sandelman.ca Michael Richardson writes: Brian =3D=3D Brian E Carpenter brian.e.carpen...@gmail.com writes: Brian And therefore intrinsically evil, just like 10.0.0.0/8 is Brian intrinsically evil. Brian IMHO we shouldn't be discussing how to make it work less Brian badly; we should be discussing how to avoid it entirely. Right, but we have installed base. Based upon comments in Jabber yesterday, I think that the right way is for fridge.local mDNS to return a series of SRV records in the additional information, one of which would contain a FQDN (having a GUA) for the fridge, if it had one. I don't know exactly what that would look like, but it seems like the right process: discovery gives us a name, and the name is sometimes a FQDN. That would also have solved Stuart's problem printing to bluehawaii, had his laptop CUPS bookmarked bluehawaii.apple.com rather than bluehawaii.local (nothing that bluehawaii.apple.com works just fine when in the office) Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works=20 It might be reasonable for mDNS or dynamic DNS to populate the FQDN with an A and record and create a CNAME in local or sitelocal that points to the FQDN. Tools like host or dig would report the CNAME, the FQDN, and the final A and/or records if sitelocal was in the search path before the domain. I'm not sure how that works with CUPS bookmarking. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] how to bookmark .lan, /.home, /.my-homenet when not home
In message 5615.1343689...@sandelman.ca Michael Richardson writes: while reading drafts on the airplane, I have come to think that picking any specific name a la .local for the homenet name service is fraught with RFC1918-like confusion. For the actual printer and refridgerator (which does not move, but needs to talk to the TV) it's not a big deal, but for mobile devices, I think it's gonna lead to confusion. When I'm at your house, and I visit fridge.local, do I get your fridge, or mine? Assuming I want mine, if I've discovered it when I was at home, how would I bookmark and remember it, assuming it had a GUA? I therefore propose adding a level of indirection (because that solves every problem), which (mobile) hosts will ideally become aware of. I think of this as a layer above the current LLMNR/mDNS/Bonjour++ layer. If you have your own domain, whether by default you get your fridge or the one at the site that you are at depends on whther your domain is ahead or or after sitelocal in your DNS search path. This affect only how a short name like fridge gets expanded into a FQDN. You can still access either fridge. Printer might be a good example. Use the one at home or have a copy printed where you are now. I've printed things from remotely a few times for my wife to pick up at home and sign. And I've also wanted a local copy at times. My idea is that the .homenet/.local discovery protocol would, in addition to the ULA or GUA record, would provide a reference a unique name which might not be globally resolvable from the DNS root, but can be resolved by arrangement. This would be not unlike split-horizon DNS, but given IPv6 reachability, no VPN necessary. If I'm at your house I don't want to have to configure your router so I can talk to my printer. Also, not local can mean on a mobile device including a mobile phone or at a WiFi hotspot. I don't think the barista is going to allow you to configure their router to share with you local DNS. For sites where mglt-name-delegation works, great, use that! For those where this doesn't work, we need a new well known name. Perhaps it can find a logical place in arpa. Let's say it's based upon the ULA, and the home with prefix A:B:C:D gets D.C.B.A.homenet.arpa. (add this to DNS search path...) When an application resolves fridge.local, if the fridge has a GUA which it has provided to the CPE's DNS server, then it also returns a pointer to the long-term name (probably in a new RR) like fridge.D.C.B.A.homenet.arpa. Any bookmarks and the like would contain that address (HTTP/HTML has existing mechanisms to deal with this), other applications might see this as the canonical name. (getaddrinfo(3) already has a canonname) My idea is that given IPv6 reachability for the HOME's CPE(s), that a mobile recursive (secure) DNS resolver can learn to make queries for D.C.B.A.homenet.arpa. directly to the home CPE, even when the mobile device is not at home. The mobile device needs to be paired with the CPE such that it agrees to do this side-ways lookup. It's pretty much identical to a windows desktop joining an AD (but I can't speak to the home edition being able to do that... don't do windows). This process is, I admit, a form of walled garden DNS, something I've argued against as being unnecessary. I'd rather that the ISPs provided a name, but I feel that ISPs won't be very fast to offer this, and for the home user with no native IPv6 (using a managed tunnel, for instance), that a protocol such as I am suggesting, would provide a clear value (something people would brag about to their friends...) without requiring people to wait for their ISP. This does not replace fridge.local referring to the fridge on the network that you are on, but it does provide a way to easily discover and then bookmark my fridge. (written offline using xemacs on android) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reverse DNS
Ted, I'm agreeing with you that there are other uses for PTR records than a misguided notion of security. Every log file that tries to record host names becomes much more readable if it is successful in recording host names than if it records IP addresses. In some cases for performance reasons the log files have to record IP addresses, but that would not be expected to be the case for home use. It is even worse if the log files record IP addresses and the person reading the logs has no reverse map. The example cited by Michael in http://www.ietf.org/mail-archive/web/homenet/current/msg01286.html is a good one. Particularly the double use case in that example. Since a home user is not likely to know to consult DHCP logs or dynamic (m?)DNS logs, that use case where the provider logs had DNS names is a good example. Curtis In message 5b72c03d-18e1-42be-9263-544b672ba...@fugue.com Ted Lemon writes: --===3943190178831859519== Content-Type: multipart/alternative; boundary=Apple-Mail=_9BAA1259-B71E-4867-8EF8-F0FF03A0821C --Apple-Mail=_9BAA1259-B71E-4867-8EF8-F0FF03A0821C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 30, 2012, at 4:59 PM, Michael Thomas wrote: Maybe I missed it, but why is lack of reverse map a problem, minus the security desire to show some weak control of the allocated prefix? This is the wrong way to ask the question. Let me restate it: Is there some application for the reverse DNS, aside from the totally = useless security provided by matching the PTR with the ? The answer is yes. There are a number of uses: peer-to-peer = rendezvous, a place to publish keys, debugging info are examples. = AFAIK there is no controversy about the fact that that using the PTR = record as a confirmation that you are who you say you are is completely = useless and should not be done. --Apple-Mail=_9BAA1259-B71E-4867-8EF8-F0FF03A0821C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii htmlhead/headbody style=3Dword-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = divdivOn Jul 30, 2012, at 4:59 PM, Michael Thomas = wrote:/divblockquote type=3Dcitespan class=3DApple-style-span = style=3Dborder-collapse: separate; font-family: Helvetica; font-style: = normal; font-variant: normal; font-weight: normal; letter-spacing: = normal; line-height: normal; orphans: 2; text-align: -webkit-auto; = text-indent: 0px; text-transform: none; white-space: normal; widows: 2; = word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; = -webkit-border-vertical-spacing: 0px; = -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; font-size: medium; Maybe I = missed it, but why is lack of reverse map a problem, minus = thebrsecurity desire to show some weak control of the allocated = prefix?br/span/blockquote/divbrdivThis is the wrong way to = ask the question. nbsp; Let me restate it:/divdivbr/divdivIs = there some application for the reverse DNS, aside from the totally = useless security provided by matching the PTR with the = ?/divdivbr/divdivThe answer is yes. nbsp; There are a = number of uses: peer-to-peer rendezvous, a place to publish keys, = debugging info are examples. nbsp; AFAIK there is no controversy about = the fact that that using the PTR record as a confirmation that you are = who you say you are is completely useless and should not be = done./divdivbr/div/body/html= --Apple-Mail=_9BAA1259-B71E-4867-8EF8-F0FF03A0821C-- --===3943190178831859519== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet --===3943190178831859519==-- ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] how to bookmark .lan, /.home, /.my-homenet when not home
In message 1314.1343756...@obiwan.sandelman.ca Michael Richardson writes: Kerry == Kerry Lynn ker...@ieee.org writes: When I'm at your house, and I visit fridge.local, do I get your fridge, or mine? Kerry Mine, by definition. Given that I'm not sure how you mean Kerry .homenet Kerry to work by comparison, I'm not sure I completely understand Kerry the rest Kerry of the discussion. Yes, I agree that when I lookup fridge.local, I'll get yours. *unless* the mapping to a GUA is still in my browser's cache... (I deleted a realistic situation for my smartphone talking to my stove to find out when the roast is done) So what I'm after is a way for the fridge to say, when I lookup fridge.local that it's GUA is 2001::F001 (mDNS can already do this), but also that it's unicast DNS name is fridge.kerlyn.com. Regular DNS can do that too. :-) [btw - this wasn't dyndns] host fridge fridge.ipv6.occnc.com has IPv6 address 2001:470:1f07:1545::4:f00d That only works because ipv6.occnc.com is in my search path. In the prior example I gave if sitelocal was in my search path and there was no DNS name given to my zone, then I'd get fridge.sitelocal. If OTOH a provider gave me curtis.site.myprovider.evil then I'd get fridge.curtis.site.myprovider.evil in response to a host fridge command. That is because the provider would put curtis.site.myprovider.evil in the domain and search response in DHCP and the router would pass it along. [btw- I don't have a ISP provided email (that I know of) and I doubt curtis is not taken, however the contact email for them is cur...@occnc.com.] Kerry If you are remotely accessing resources in your home, you Kerry are probably Kerry more advanced than 99% of all home network users. Why wouldn't the Kerry solution you use on the road apply equally well at your Kerry neighbor's house? Kerry, the point of end-to-end connectivity into the home is to permit the things that us 1% do, to be doable by everyone... Right? Exactly. So, yes, dyndns is *a* solution, but I don't know how to automate it in a scalable way. I'm concerned that for the homenet protocols to be incrementally deployable (create value) that we can not rely too much on the ISPs doing the right thing for forward DNS delegation. The dyndns would be localized to the site. The provider just delegates a name to use that is a subdomain of their own, or as I suggested in an earlier email, perhaps of the form customer-email.site.provider-fqdn. That would be completely static and set up at customer service setup and never changed. At worst, the customer could opt not to use it or have equipment that can't make use of it. A provider run DNS secondary would similarly just be statically configured. Today the customer is given a dynamic address (unless explicitly asking for and paying for a single static address). That is because IPv4 addresses are in short supply. IPv6 /64 prefixes are not is short supply, therefore a provider supporting IPv6 native (or tunnels) could easily offer a static /64 reserved when the customer service is initially setup and never changed until the customer leaves. This is two things configured on the provider side when the customer is setup and never touched until the customer leaves. That is not a large burden on the provider dns ops staff. Kerry I think defining new zones under .arpa. may have merit in Kerry the following Kerry respect: ICANN is now in the business of selling dotless Kerry domain names. Just to be clear: my idea isn't that IETF run a dyndns under arpa, but that we have a WKN under arpa which is treated specially. The homenet.arpa subdomain adds nothing IMHO. If the provider is completely non-cooperative in all ways except basic IPv6 connectivity and granting a /64 via DHCP or statically configured on provider owned CPE, then the customer simply gets fridge.sitelocal and can't access his own fridge from the neighbor's house. I understand that my idea is hard to evaluate without a document. Should I write one then? Could you summarize in an outline what you would put in that document? Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] how to bookmark .lan, /.home, /.my-homenet when not home
In message 7732.1343758...@obiwan.sandelman.ca Michael Richardson writes: Curtis =3D=3D Curtis Villamizar cur...@occnc.com writes: Curtis The issue is what happens when *my* fridge is not on the same h= ome Curtis subnet as *my* home computer. (Sustituting a more realistic ex= ample, Curtis like thermostats, water heater, alarm system, etc, where temp/t= ime Curtis profiles might be altered, but we'll stick with the fridge Curtis example). this is an issue, and we have some proposals to solve this. It's not the issue that I'm talking about. I'm saying that I want to leverage the sitelocal host discovery protocol to also discover a global name for the host. I'm suggeting that an application (e.g. browser, cups, etc.) on a mobile device should never (by default) actually bookmark fridge.local, because it's not globally meaningful. Curtis A separate issue is how to address the fridge from a computer a= t work Curtis or a mobile phone where clearly neither are on the same site. = Here a Curtis domain name has to be assigned and most likely something of the= form Curtis subdomain.provider-fqdn if there is not going to be a regis= tration Curtis fee. The subdomain might be the same as the email address prov= ided by Curtis most home providers or email.site.provider-fqdn. At worst = the Curtis mobile phone would need to have email.site.provider-fqdn in= the Curtis DNS search path so fridge can be resolved. Curtis The sitelocal name then only serves a purpose when the site is = not Curtis connected to the provider and doesn't know its domain name. It's not a hard problem, technically (layer 1-7) It's a hard layer 8/9 problem, and I'm suggesting that maybe we need to think about whether there are layer-5/6/7 things that we can do as we are specifying the sitelocal discovery process to ease the layer 8/9 problem. =2D-=20 Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works=20 Getting sitelocal allocated should be no more difficult than getting local allocated. It is a TLD that does not resolve globally but does resolve differently at each site. It can be used in the absense of a DNS domain. It can also be used in the absense of IETF action and in the absense of provider cooperation because no one can stop you. :-) But I'm not advocating doing that. host fridge.sitelocal fridge.sitelocal is an alias for fridge.ipv6.occnc.com. fridge.ipv6.occnc.com has IPv6 address 2001:470:1f07:1545::4:f00d [ :-) no cooperation from IETF or from my provider required and no harm done. I could have made it an record rather than a CNAME. To see this you need to direct queries at my name server. fridge.sitelocal is entirely local. fridge.ipv6.occnc.com is in the global DNS. Please don't try to ping6 my fridge. It won't answer. ] Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] section 3.2.2.1 of homenet-arch
In message 50181a1c.5050...@gmail.com Brian E Carpenter writes: On 31/07/2012 17:59, Michael Richardson wrote: Brian == Brian E Carpenter Brian writes: I'm also surprised that we think we have to cope with flash renumbering as a regular event, rather than a service-interrupting, ISP truck roll catastrophy. Brian But every time you reboot your antiquated v4-only CPE Brian and/or the antiquated Brian v4-only PCs behind it, the PCs all get new IP addresses, Brian which may or Brian may not be the same as the previous time. There's nothing Brian new in flash Brian renumbering for homenets. Not handling this would be a step Brian backwards. Well... 1) sure, but the *customer* does this, not the ISP. 2) the clients do have DHCP leases, and if they ask to renew their previous IP, it usually gets honored. It doesn't matter whether it's the user or the ISP that triggers a change, does it? The point is, users don't care about this, except if they reach their shiny new wireless printer via its IP static address. There are definitely parts of draft-ietf-6renum-static-problem that apply here. Brian Brian, Enterprise renumbering and homenet renumbering are generally quite different. Most homehets have short uptimes. Most enterprises have very long uptimes. (insert favorite Microsoft reliability joke here). If a renumbering is done right, there is an time when both the old and new numbers are in use. As in ifconfig intf inet6 newaddr ... alias in the *ix world. During that transition time any use of DHCP will hand out the new address. Then comes a time when the leases refuse to be renewed. Then the old addresses go away. This can be day, weeks, or longer depending on the size of the transition. During that time a lot of please reboot at least once ... messages get sent. Today there is no DHCP help in avoiding the please reboot messages. It should be possible for a DHCP client (ISC guys, are you out there?) to do the following if a lease can't be renew and a new address is provided: 1. Add the new address using an ifconfig intf ... alias equivalent. 2. Check (using netstat -an equivalent) for use of the old address. Don't delete the old address if a socket still exists. 3. Periodically repeat step 2 until there is no connection using the old address. 4. Delete the old address using the equivalent of ifconfig intf ... -alias. This would work for all client side connects that either were done before the end of the transition period. For home nets this covers 99.something percent of the sites with no user intervention or reboot. This requires no protocol change, just better coding in the DHCP client software. What this does not cover is a service that is listenning on a well known port. This is rare among home nets (except for homes of readers of IETF lists) but very common among enterprises. Many points made about license servers, etc in draft-ietf-6renum-static-problem don't apply to home nets. Renumbering an enterprise is doable. Renumbering my home net has been quite easy. I've done it a few times already and I'm sure will have to again. The procedure suggested above is just done manually. One hint is that on BSD and Linux at least a netstat -an should reveal any listens on old addresses. An automated scan on an enterprise network can identify servers and services needing a reconfig and a service restart without any system reboot. [ Microsoft systems may need to reboot or power down and remove the CMOS battery from the motherboard or maybe buy new hardware. :-) ] In IPv6 space, the host part will generally stay the same (modulo privacy extensions, which are default on for some clients). We've said that the ULA ought to stay the same, so in fact, I agree, the internal addresses actually all stay the same. I'm still surprised that an ISP will need to flash renumber faster than it can just expire leases. If it's just repartitioning of network to deal with growth, that ought to be predictable and prefix lifetimes can be reduced in advance. If it's actually some equipment failing, resulting in service interruptions, and then restoration by rewiring the network... then I understand. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reverse DNS
In message 2034.1343768...@obiwan.sandelman.ca Michael Richardson writes: Curtis =3D=3D Curtis Villamizar cur...@occnc.com writes: Curtis Every log file that tries to record host names becomes much more Curtis readable if it is successful in recording host names than if it Curtis records IP addresses. In some cases for performance reasons the log Curtis files have to record IP addresses, but that would not be expected to Curtis be the case for home use. It is even worse if the log files record IP Curtis addresses and the person reading the logs has no reverse Curtis map. the machines recording the addresses/names are not in the home. They are the web servers that the home user talks to. Yes. I know that. Or a mail server, etc none of which is not in the home. If a problem is reported to the home user, then having a mapping of address in the logs to host name would be a real good idea. http logs on heavily loaded servers always record just the IP address because the overhead of the rDNS lookups is too high. I mentioned that in prior email. Very rarely is an end customer ever contacted, except perhaps an automated mail from postmaster on an email server or a rare note from a provider saying their host is compromised and is attacking others. Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works=20 IETF ROLL WG co-chair.http://datatracker.ietf.org/wg/roll/charter/ Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
In message 50188eb0.2040...@mtcc.com Michael Thomas writes: Since I apparently got a few heads shaking today from my jabber comment, I guess I should at least throw it on the list. My observation -- and I'm not necessarily saying it's a [good] solution -- is that one way that we could deal with the ambiguity of what fridge.local[site] means when I elsewhere is to say that .local[site] is exactly what it says it is: a property of the local site. As such, if I'm roaming and do not have topological connectivity, the proper way to get that connectivity would be to use some form of tunneling back to the .local[site] I actually intended and thus be part of the .local[site] topology again. On the plus side, this puts it into the hands of somebody to deal with the ambiguity. On the minus side, this puts it into the hands of somebody to deal with the ambiguity. Mike For a mobile device, including a laptop, sitelocal should reflect where you are. In someone else's house, printer.sitelocal should be their printer. If that someone else gives you authentication credentials or you give then a public key and they install it on the printer, then you can print. Today, more likely the home printer is USB and you plug it in to your laptop. Getting to your own fridge or printer from elsewhere would require that you have a domain name and know what your domain name is. Presumably you'd already have whatever you need for authentication. There is no ambiguity. It is a personal choice whether you want to put sitelocal first in the search path or your own domain first. I suggest that your own domain would be a better choice. fridge means the same thing no matter where you are. fridge.sitelocal means the fridge near you if you are elsewhere. fridge.sitelocal. is a FQDN with site local scope. fridge.yourdomain is a FQDN with global scope. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
Correction. A mobile device on the a site's wireless LAN would see fridge.sitelocal. The cellular provider would be better off just populating sitelocal with any services offerred by the cellular provider, such as mediadownload.sitelocal or ntp.sitelocal (unlikely, but hopeful). Sitelocal might be problematic for a mobile phone in a fast moving car on a highway through an urban area. Sitelocal would change with each cell tower handoff. Curtis In message 201208010448.q714m8ki091...@gateway.ipv6.occnc.com Curtis Villamizar writes: In message 50188eb0.2040...@mtcc.com Michael Thomas writes: Since I apparently got a few heads shaking today from my jabber comment, I guess I should at least throw it on the list. My observation -- and I'm not necessarily saying it's a [good] solution -- is that one way that we could deal with the ambiguity of what fridge.local[site] means when I elsewhere is to say that .local[site] is exactly what it says it is: a property of the local site. As such, if I'm roaming and do not have topological connectivity, the proper way to get that connectivity would be to use some form of tunneling back to the .local[site] I actually intended and thus be part of the .local[site] topology again. On the plus side, this puts it into the hands of somebody to deal with the ambiguity. On the minus side, this puts it into the hands of somebody to deal with the ambiguity. Mike For a mobile device, including a laptop, sitelocal should reflect where you are. In someone else's house, printer.sitelocal should be their printer. If that someone else gives you authentication credentials or you give then a public key and they install it on the printer, then you can print. Today, more likely the home printer is USB and you plug it in to your laptop. Getting to your own fridge or printer from elsewhere would require that you have a domain name and know what your domain name is. Presumably you'd already have whatever you need for authentication. There is no ambiguity. It is a personal choice whether you want to put sitelocal first in the search path or your own domain first. I suggest that your own domain would be a better choice. fridge means the same thing no matter where you are. fridge.sitelocal means the fridge near you if you are elsewhere. fridge.sitelocal. is a FQDN with site local scope. fridge.yourdomain is a FQDN with global scope. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reverse DNS
= James = Ted In message 47b88b0c-ea3e-4222-85a1-95c9d1e67...@fugue.com Ted Lemon writes: On Jul 30, 2012, at 11:52 AM, james woodyatt wrote: 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. The work's already started in the dhc working group: http://tools.ietf.org/id/draft-lemon-dhc-dns-pd-01.txt I'd be curious to hear your feedback on this draft. In most cases where a site has delegation of DNS or rDNS. it is not negociated using DHCP. This draft appears to allow that extension. That is good (IMHO). I think it would be wonderful if providers offered delegation of rDNS and making it trivial for them might not hurt. [Aside: my ISP will not do delegation of rDNS. You have to put in a support call (not web page, not email, a phone call) for any change and that is hugely time consuming for me, and very time consuming and therefore expensive for them. My ISP is stupid in some ways. My IPv6 tunnel provider OTOH has an option on their web page to specify where the rDNS name servers reside and it all works very nicely. Native IPv6 would be better but only if my ISP had a clue about rDNS.] Back to the original email. 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. James gave an example and I don't know what his gripe was, other than getting rDNS to work was not something the home user could tolerate. I agree with that usability point. Looking at the practical side, right now there is a good tie in between ISC dhcpd (DHCP server) and ISC bind (DNS server) for forward DNS. I don't think that rDNS is handled by ISC but I could be wrong. Even so, there is nothing preventing rDNS from being handled. The issue is then that rDNS (like DNS itself) is hard to configure with some of today's tools. ISC tools (for example) are powerful but hard to configure. Some low end routers exist that are much easier to configure, but they lack capabilities. Some of the prior discussions centered around using a default zone of local, such that if a host claimed to be host name foo and another claimed to be bar then the fqdn would be foo.local and bar.local. It would then be a small matter of configuration to change local to example.com and have the fqdn reported by rDNS be foo.example.com and bar.example.com. For any of this to make sense some configuration is needed. Someone has to configure foo as the host name on one host, and bar as the host name on the other, and maybe if they have just one router, they could give it a name too. This would be simple enough to configure. No protocol extension is neede to accomplish this. This is something that could be mentioned in a homenet arch document if we decide that the default local domain is a good idea (and get the appropriate blessings on this use of that TLD) and that dynamic DNS and dynamic rDNS should be available and enabled by default. There are two decisions to be made 1) dynamic DNS and rDNS should be available, 2) they should be enabled by default with local domain, easily configured to another name. btw - Even without delegation, accurate rDNS can be provided *locally* which for some users (like those using the default local domain) would be sufficient. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing requirements
Trimmed, leaving only responses to the points Lee brought up. In message 1dd9deae-0f85-41a1-b4c9-c8c09bc84...@twcable.com Howard, Lee writes: This almost covers one of Jim's points. Jim added unitentional join. a. Convergence time a few minutes or less. Seconds at least. Goal for providers is 60 msec, but subsecond would be a reasonable goal for wired. Why would we need that level of repair? This is a home network, not a carrier network. On wired it is easy to get subsecond in a small topology. It would be nice if you streaming audio, movie, phone call to support, etc, stayed up when a minor change was made as long as connectivity still existed. 7. Best-path is a non-requirement. It should be a goal but not a hard requirement. Why? Having your HD video stream avoid the 10baseT hub that you have never bothered to through out would be a good thing. It could also be said that today the slowest thing out there is 10/100, but why not take a GbE path if one is available. Any why not take one 10/100 hop instead of two? Its a worthy goal since some application will eventually want the bandwidth, even if temporarily. With wireless, best path might be more important, but it seems to be a more ellusive goal. At least some people are arguing against it. 8. Support for multiple upstream networks is a requirement. a. Including wireless offload, video-only, and split-tunnel VPN scenarios. b. With separate routers to each. Not multihomed off the same router. c. Prefix delegated from all ISPs (upstreams). This will be hard and may require detection of hosts with new capabilities and a (less functional) fallback strategy for others. Yes. Maybe this should be an assumption, not a requirement, and the resolution of issues around it is dependent on how we do address assignment. The trouble here is that there's no way for two ISPs two coordinate prefix assignment, so they will both reply with IA_PD, and two routers will try to use those prefixes. We need to assume that sometimes there will be cluefull and cooperative service providers upstream, and sometimes there won't be. Today some configuration is required on almost any provider uplink. In the case where the provider installs and completely controls the CPE, and the demarc is the ethernet the other end may just act as a DHCPv4 server and won't do anything else. Then it is hard to identify this as an uplink as there are all sorts of consumer products today that do DHCPv4 and claim to have a default route even though there is nothing connected on the uplink side. If the provider does respond to an IA_PD with a glocally routable prefix of length /64 (or less specific), then it can be assumed to be an uplink. It may also be doing IPv4 NAT and hand out private address space typically in 192/24 or 10/8. d. ISP A is default. e. With only traffic destined to ISP B's prefix using that link. f. With a backup default to ISP B, if desired. What is default condition? With no designated A or B, closest is the default, with hysteresis. A tie breaker rule would be less desireable. What does closest mean? Longest match? Closest means what closest has always meant: least cost, ie: best path. Least cost is a function of how the routing protocol deals with metrics. This is intended as a deterministic and unambiguous tie breaker. 9. Cannot assume hierarchical prefix delegation in the home (at least, not unless the WG develops such a solution). Here I disagree. Must assume hierarchical prefix delegation. ULAs are not globally routeable. ND proxy will fail Jim's scalability test in an instant. I would prefer a hierarchical solution. I have not been able to finish writing up my proposed solution, but it's pretty much wait to see if anyone else needs a prefix from you, then request all the prefixes you need. Here again, what assumptions we take for routing depend on what we do for address assignment. Until then, I think we should not assume hierarchical delegation. Off topic a bit (your proposed solution). If everything powers up and waits for someone else to ask for addresses, then only the hosts ask. The routers then ask each other in random order and those that are not direct uplinks have no basis for a response. If everything asks first, then the uplinks will be the only ones to respond quickly. The responses will progress from the uplinks along the topology until all parts of the topology have one or more prefixes suballocated from the prefix that was provided to the uplink(s). In the absense of legacy devices, all but the closest age out if they were assigned before the closest. In the cast where there is no uplink, after a brief timeout ULAs start being assigned for the purpose of bringing internal routing up and having internal connectivity. Again if an uplink
Re: [homenet] routing requirements
In message dcc302faa9fe5f4bba4dcad4656937791451335...@prvpexvs03.corp.twcable.com Howard, Lee writes: -Original Message- From: Curtis Villamizar [mailto:cur...@occnc.com] Sent: Friday, October 21, 2011 11:14 PM To: Howard, Lee Cc: Samita Chakrabarti; homenet@ietf.org Subject: Re: [homenet] routing requirements In message dcc302faa9fe5f4bba4dcad4656937791451334...@prvpexvs03.corp.twcab le.com Howard, Lee writes: Can you describe some scenarios which would cause a prefix to change, in which applications break in ways that are unacceptable? All of the ones I can think of would be cases where I would expect a session to drop, but I'm sure that's a lack of creativity on my part. Lee Most IPv4 hosts can't tolerate their IP address going away. For IPv6 its slightly easier because they can add a new address in a new prefix. Only think is the host need to ask for an address and today if its lease has not expired it won't ask. Some older DHCP code won't take a change in address or default route when the lease expires. The case we were talking about, I think, was a link or device failure. One expects an outage in those cases. If you have two uplinks, you shouldn't need to reboot everything your house to get connectivity back up because hosts and routers are using a prefix that is no longer globally routable. One thing that would break is any open TCP connections. The open connections use the already selected address. This has been a problem for mobility for quite a while but those heavier solution can't be applied to this problem. TCP is not expected to be resilient to outages. We're not building a carrier network, we're building a home network. Bounce the connection. No one is suggesting we try to avoid dropping an open TCP connection on a down transition from the uplink that provided the address the host is using. Concievably a TCP extension could support alternate source addresses (such as SCTP does). Until then, a TCP connection can't change addresses. If you switch from one provider uplink to another, you should be able to keep talking to your content provider. Currently you can't. For web users, hit the stop and the reload. Web, p2p, gaming, VPN. . . I'm okay with the session dropping in case of failure. Yes. This is not a TCP ng WG so we don't try to fix TCP here. There are cases like two uplinks to the same provider (same /64 prefix) that would work without any effort. This would be rare in the home though not unthinkable in a home or small business and not uncommon in medium and large businesses. We should make it possible for multihoming scenarios such as this to work, preferably with no configuration, except at the provider. For example, an extension to IA_PD essentially saying use X/65 which came from X/64 and has no firewall enabled yet would allow the provider to do all the configuration needed to make this workable with zero config on the customer side. Lee Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing requirements
In message CAD6AjGQG2p=v+0z3x6ab+ggw1bo2dizp6ztvik3b7uo-o95...@mail.gmail.com Cameron Byrne writes: On Oct 24, 2011 1:24 AM, Ray Bellis ray.bel...@nominet.org.uk wrote: On 22 Oct 2011, at 01:18, Hemant Singh (shemant) wrote: Note the IETF IPv6 CE router specifies use of the ULA in the home to keep the home network independent of the SP network. This way my computer at home can still print to the printer even when my SP IPv6 network is down. We have said this multiple time in v6ops during development of the IPv6 CE router RFC 6204. Thanks for the reminder. FWIW, I believe the consensus _is_ for ULAs within the home network, although I do see a few vocal opponents. I don=92t have the time to read the copious emails of homenet, but seeing some emails here and there I see homenet regressing on issues that are closed in the v6ops IPv6 CE router document development. Examples of issues homenet is regressing on is ND Proxy and use of zospf for prefix delegation in the LAN. There was only one cell phone vendor who was asking us for ND Proxy with a single /64 PD delegated to the phone. We convinced the vendor at the Prague IETF to abandon that idea because such a /64 would need RA Proxy in the CE router and RA Proxy is not defined is any RFC. Thus the vendor agreed and decided to go with DHCPv6 PD of RC 3633. That is why ND Proxy was removed from the cpe rtr bis document. Will those arguing for ND Proxy please stand up and be counted? I am not arguing for ND proxy, just saying the mobile device may use it to extend their connectivity into the house. So I am not saying the home route= r will do nd proxy, unless you consider the mobile attached device to be the home router itself. There is no standcardized support for dhcp-pd in 3gpp yet, it is in the pipe, and deployment will vary. Nd proxy is not a bad solution here. In the case of 3gpp mobile device, nd proxy is only extending the users's attached /64 p2p link onto a LAN, it is not sharing with other customers or provider infrastructure. Cb The homenet work will have to interoperate with whatever 3GPP has defined, but does not have to recommend any further use of ND proxy. The work in homenet might (or might not) affect what 3GPP does in the future if there is compelling reason to do things differently. Zospf was also closed in v6ops that it=92s not possible to use for prefix delegation in the LAN. Here is an email to v6ops on closure on ospf for prefix delegation. Again, thanks, that's useful background. Ray I don't think there have been any arguments in favor of using OSPF or ZOSPF as the address assignment protocol. There have been arguments (from me at least) to allow that the assignment protocol take hints from whatever routing protocol is in place as to which prefixes were originated from closer uplinks. This allows the use of a prefered uplink (ie: wired provider preferred over wireless provider) or a closest path out to equally preferred providers. There are also arguments for OSPF as a routing protocol, with extensions where needed, such as better automated router ID selection. There are also arguments for as useful a result as possible with zero configuration as a goal for whatever protocols or usage is defined in homenet, independent of whether OSPF is in any way involved. The death of zospf as an address assignment protocol in v6ops does not negate these points. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing requirements
In message c5e8c3ca-ba31-4af7-abb2-729e8629b...@apple.com james woodyatt writes: 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 I'm not sure what you are advocating. (Except having read ahead I know whatever it is Dave Thaler agrees with you). It seems to me like you are advocating treatment of WPAN as a special case stub with very limited capability appropriate only for a stub. Is it possible for a WPAN-only connected device to have more than one reachable device which could provide connectivity to a wired (or WiFi wireless) network and eventual connectivity to a controlling host? Is it also possible that a mesh of WPAN devices could exist? If so, then WPAN is no longer a special case stub, it is mearly a low power device with limited radio coverage and/or limited bandwidth. For example, a potential application of WPAN is home security. With routing each window or door or motion sensor need not be within reach of the control unit, just within reach of another window or door or sensor. This would be a mesh application in the home. The bluetooth limitation where the headset has to be near the phone or computer need not constrain what WPAN is used for in the future. The effective range can be extended as long as the device is near *something* that does WPAN and the something has other connectivity or is part of a mesh that has other connectivity. I did mention that devices need to be bonded to each other somehow. These WPAN applications are a case where this is important. The more the range of the WPAN is extended, the more you wouldn't want it to be too easy to spoof the home alarm system or have anything connect to a given phone or headset. Of course, limited range is no excuse for the situation with bluetooth headsets in airports where everything bonds with everything else because they all use a manufacturer's default. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet Architecture Interim Meeting
In message dcc302faa9fe5f4bba4dcad4656937791451334...@prvpexvs03.corp.twcable.com Howard, Lee writes: I do not adhere to default permit as a security principle. Then you also do not care for supporting the e2e principle, and I thought I heard people mumble e2w was a good thing at the start of homenet. I am in the camp the host should be strong and smart and networks should be simple and fast. Cb Let's discuss the end-to-end principle and see how it applies here. rfc1958 quotes from [Saltzer]: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) In this instance, the function could be considered either a) implementation of a forwarding policy, or b) the application sending/receiving packets. If (a), then is is being done with the knowledge and help of the application, so the principle is intact. If (b), then the firewall is not attempting to implement that function, only to forward or not forward packets, and the principle is intact. All of the examples contemplated in rfc1958 and in the original paper are about adding processing to packet forwarding, such as error checking, encryption, or deduplication. In this case, the host (or application) is establishing a security policy, and asking for help enforcing that policy. A general security principle is to drop malicious traffic as close to the source as possible (rfc3013, rfc3871). the end-to-end argument is not an absolute rule, but rather a guideline that helps in application and protocol design analysis http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf People can argue that the end-to-end principle prohibits use of stateful firewalls. I believe that properly implemented, where the host (application) sets the policy and the gateway/firewall makes a forwarding decision, the principle is upheld. Lee Lee, What people are arguing is a violation of the end-to-end principle is having a provider put in place filters that can't be shut of by the consumer. It would be preferable if the consumer could shut them off completely with at most one support call and then take responsibility themselves or better yet have configuration control over the firewall. If a mechanism is provided to poke pinholes, that may be acceptable to some. PCP may not be acceptable to many, preferring a configuration (persistent) change to the firewall. I for one would rather you shut off any firewall that you provide and leave it to me (and I would find another provider if you couldn't do that). But that is not typical. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing requirements
In message
16d60f43ca0b724f8052d7e9323565d7243f7eb...@eusaacms0715.eamcs.ericsson.se
Samita Chakrabarti writes:
Hello Howard,
Thank you very much for the summary of messages.
A comment on item 12:
12. Prefix stability?
SC I expect that 'Prefix Stability' is a requirement at home or small
SC offices. Without prefix stability some of the applications will
SC suddenly break when the old prefix expires and the new prefix
SC becomes effective.
And question to the wg:
8. Support for multiple upstream networks is a requirement.
g. Source address selection is out of scope. And should be solved by
rfc3484, with longest prefix match (whether ULA or walled garden).
Choosing which address to use to look up the destination address is
out of scope.
SC Is the expectation from homenet wg that all hosts will implement
SC RFC 3484 ?
SC Do the current home IPv6 host products support RFC 3484 ? [ I
SC don't think so ] So the host implementation change should be
SC required if a host has to support multiple prefixes or I might be
SC missing something?
Thanks,
-Samita
A host can only be assigned multiple prefixes and have one essentially
taken away if it is know to be OK with it.
An extension (to an address allocation such as DHCP{4,6}) can easily
be crefted that allows the host to communicate the capability. Prefix
stability is then only a requirement for the legacy hosts. Any more
recent hosts can give up an address.
AFAIK all OS today support IPv6. All recent hosts should support RFC
3484 (it is a 2003 RFC). You'll still find some very old software out
there, so not all. Worse than no IPv6 would be old broken IPv6 code.
I don't think this WG should focus on that small minority.
Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing requirements
Address assignment must be a separate protocol so that it is not tied to one specific routing protocol. OTOH it can (and IMO should) make use of hints from the routing protocols at to where the uplinks are and how close they are in selecting among available addresses. For IPv4 where DHCP likes to see one address only, supporting legacy hosts is a harder problem. Any extension mean that accomodation have to be made for legacy hosts. Curtis In message 16d60f43ca0b724f8052d7e9323565d7243f7eb...@eusaacms0715.eamcs.ericsson.se Samita Chakrabarti writes: --===2644728098816532559== Content-Language: en-US Content-Type: multipart/alternative; boundary=_000_16D60F43CA0B724F8052D7E9323565D7243F7EB191EUSAACMS0715e_ --_000_16D60F43CA0B724F8052D7E9323565D7243F7EB191EUSAACMS0715e_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Thanks Hemant for the information from V6ops discussion on zospf prefix del= egation. In my humble view: - Prefix assignment should be independent from a routing protocol - Binding prefix-assignment to a routing protocol creates the problem of sy= nchronization as you pointed out and also it limits the user to a single ro= uting protocol for the network. I think the users/operators should have fle= xibility to choose a routing protocol for the services they offer today and= in future. I'd really like to see IPv6 PD solution for the home network for network st= ability after a power outage or bringing up a new set of network. We have gone through similar debate in RPL development timeframe and finall= y as far as I know RPL made the prefix configuration optional. If someone thinks that a new version of ospfv3 will introduce prefix assign= ment as a optional feature for a particular application/environment where i= t might work perfectly - I am okay with that. It is difficult for me to thi= nk OSPFv3 being the default choice to configure ip-addresses in a home netw= ork. In future, home network will grow further - I expect that there will be tw= o kinds of users at home - 1) tech-challenged users who like plug-n-play 2= ) tech-savvy users running business or running multi-level networks at home= for convenience and pleasure or whatever reasons. So it'll be a combinatio= n of big and small ip-enabled devices and lots of them... Regards, -Samita From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf = Of Hemant Singh (shemant) Sent: Friday, October 21, 2011 5:18 PM To: Howard, Lee; Samita Chakrabarti; homenet@ietf.org Subject: Re: [homenet] routing requirements Note the IETF IPv6 CE router specifies use of the ULA in the home to keep t= he home network independent of the SP network. This way my computer at hom= e can still print to the printer even when my SP IPv6 network is down. We = have said this multiple time in v6ops during development of the IPv6 CE rou= ter RFC 6204. I don't have the time to read the copious emails of homenet,= but seeing some emails here and there I see homenet regressing on issues t= hat are closed in the v6ops IPv6 CE router document development. Examples = of issues homenet is regressing on is ND Proxy and use of zospf for prefix = delegation in the LAN. There was only one cell phone vendor who was askin= g us for ND Proxy with a single /64 PD delegated to the phone. We convinc= ed the vendor at the Prague IETF to abandon that idea because such a /64 wo= uld need RA Proxy in the CE router and RA Proxy is not defined is any RFC. = Thus the vendor agreed and decided to go with DHCPv6 PD of RC 3633. That = is why ND Proxy was removed from the cpe rtr bis document. Zospf was also closed in v6ops that it's not possible to use for prefix del= egation in the LAN. Here is an email to v6ops on closure on ospf for pref= ix delegation. Hemant begin snip From: Lorenzo Colitti [mailto:lore...@google.com]mailto:[mailto:lorenzo@go= ogle.com] Sent: Wednesday, July 27, 2011 1:26 PM To: Hemant Singh (shemant) Cc: IPv6 Operations Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router Can such a default be extensible to exchange different types of informatio= n than just reachability? For example, can it propagate information such as= this is a guest network and this is an internal network or this is a pr= efix that I have tentatively assigned but do not own yet? If not, then pe= rhaps something more flexible like IS-IS would be better. Not possible because the proposal is not workable. Someone brought up usi= ng OSPFv3 for use in prefix delegation in the home LAN to our IETF CPE rout= er design team. See the questions I asked followed by the person's reply a= nd my responses back to show no routing protocol can be used to delegate pr= efixes in the LAN. I asked, HS: How do you know OSPF has converged before responding to DHCPv6= PD requests? Reply: The CE router SHOULD wait until two sequential
Re: [homenet] is this what homenet are trying to achieve? (was Re: Thoughts about routing
In message 4ea0642d.30...@riw.us Russ White writes: Its easy to detect a walled garden if you are expecting a default route from a full uplink. Unless every uplink gives you a default route... In which case you pick the closest one. Its only where the walled garden claims to have a default route but blackholes or tries to do web only and replaces content that you have trouble. Note that I had a perfectly fine workaround, which was to NAT for any device that wouldn't give up on using an old address if that address became stale. Then you might as well NAT all the addresses on the subnet. :-) No. You NAT at the border only for the hosts on the subnet that are legacy and cannot replace a DHCP assigned address with a new one. In affect you NAT the old subnet becuase the homenet hosts and routers accepted a new address. You then have more than one subnet address (aliases in ifconfig speak). In fact, OSPF already does this... What I hate is this entire idea of redistribution. A single protocol that does both DV and LS in the right places would be ideal --but I also think the existing DV protocols can be modified to provide this sort of thing. I was trying to help come to a compromise on the grand unified routing protocol problem by stating that we don't need a one size fits all routing protocol. We can have one for wired, one for AP style wireless, one for mesh wireless. I would prefer one... There is at least an assertion that some DV protocols may be better for mesh wireless. There need not be one grand unified routing protocol. In the provider world, BGP allowed the IGP to be picked per AS and allowed OSPF and ISIS (and EIGRP) to exist in different providers. As it turns out only the LS protocols endured. On packet size: OSPF doesn't have a requirement to round every hello packet up MTU which ISIS does. OSPF can send only the LSA that changed. ISIS has to send the whole LSPDU fragment which contains the change and then the receiver has to check every TLV in the packet that didn't change and find the one that did change. How many destinations do you think there will be in a home network? My guess is that we'll end up with one or two LSPs anyway. Depends on where this stuff is deployed. Think public library for example. Multiple consumer grade APs. Real wires connecting them. No wizards to help out (except maybe some volunteer with some knowledge of PCs and absolutely no clue about networking). As for rounding up, is it really that big of a deal? It's just a different solution for the same problem. A full MTU sized hello might be a big deal on a wireless mesh. Jim's comments seem to imply that and he was rather emphatical about routing protocols keeping the noise level down. :-) Russ Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about ipv6 routing (babel AHCP)
In message cakd1yr1ag3snzu+yc_wabsbutq+ydqj1a5jbahwxdzpqjf9...@mail.gmail.com Lorenzo Colitti writes: On Thu, Oct 20, 2011 at 21:59, Ole Troan o...@cisco.com wrote: but seriously, just remove it from the build. Yep. Overlay networks will never match native performance. Please don't do 6to4, please implement RFC 6204 instead. For tunnels RFC4213 is preferred over 6to4, but I do think that both should be implemented. Comcast has done a good job with 6to4, and other providers might as well. RFC6204 does specify that the WAN side can be a tunnel, but doesn't recommend any type of tunnel (I don't think having not looked just now). Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] is this what homenet are trying to achieve? (was Re: Thoughts about routing
In message 4e9eb8fd.2060...@riw.us Russ White writes: 1. No built in assumptions about whether a router has an uplink port and if so, which port it is. d. assumptions about uplinks may be learned (zero config) or configured. The biggest problem with determining what's an uplink and what's not is simply what the word uplink actually means. One of the things we've been thinking about here is walled gardens, networks which serve a special purpose, and hence don't have connectivity to the world at large. There are probably only two solutions here: 1. The provider's device needs to tell you this information. 2. You need a set of magic destinations, that the internal devices can use to orient themselves to the network topology around them. Its easy to detect a walled garden if you are expecting a default route from a full uplink. Use the route to the whole Internet if one is available. Otherwise, use the walled garden connection if that is all you have. Walled gardens really suck. They suck even worse when they are sold as having access to the Internet when they don't. We have to get rid of long lease times. If a connection goes up, its The problem here is that you're working against the rest of the world, which assumes an IP address is pretty much a permanent feature of a device, like a MAC address. I don't know how to change that mentality. Yes. If plugging things arbitrarily and rearranging them without powering any of it down is going to work, handing out long leases to legacy devices can't be done. If a device supports taking back a lease, then that is better. Note that I had a perfectly fine workaround, which was to NAT for any device that wouldn't give up on using an old address if that address became stale. #4. security a. No filtering should be done on a link that is not identified as an uplink. As long as you're okay with multiple layered devices each filtering on their uplinks (not necessarily a bad thing, by the way). I tend to think more in terms of domains, which included possible vertical divides as well as horizontal ones. An uplink is a connection to the provider. It is discovered, not identified as the port with the yellow connector. Reread the very first sentence you quoted: No built in assumptions about whether a router has an uplink port and if so, which port it is. b. By default strong filtering should be enabled on any uplink. c. Filtering can be weakenned, holes punched through, or disabled by configuration. Agreed. OK a. DV and LS routing can mixed within a domain. DV routes can be In fact, OSPF already does this... What I hate is this entire idea of redistribution. A single protocol that does both DV and LS in the right places would be ideal --but I also think the existing DV protocols can be modified to provide this sort of thing. I was trying to help come to a compromise on the grand unified routing protocol problem by stating that we don't need a one size fits all routing protocol. We can have one for wired, one for AP style wireless, one for mesh wireless. For (a) we should recommend one. OSPF is full standard and is cleaner but we have v2 for IPv4 and v3 for IPv6. ISIS has NSAPs as router ID (even uglier than IPv6 addresses or MACs and must be unique), sends around really big packets even for small changes, but supports both IPv4 and IPv6 in one instance and is (strongly) prefered by some. I would argue that the router ID situation in IS-IS is actually easier to deal with than the one in OSPF. With fragmented LSPs, I don't think the packet size in IS-IS is any worse than OSPF, either (?). On packet size: OSPF doesn't have a requirement to round every hello packet up MTU which ISIS does. OSPF can send only the LSA that changed. ISIS has to send the whole LSPDU fragment which contains the change and then the receiver has to check every TLV in the packet that didn't change and find the one that did change. Perhaps there can be a negociation with the zero config default being a slight preference for X where each vendor gets to pick X and the slight preference could be overridden by a configured (strong) preference. Perhaps distance to any router with a configured preference can be a tie breaker to switch over (with *lots* of hysteresis on the switch over). If we can't pick one then we have to make a network interoperate in a zero config situation with vendors that had different slight preference choices. It means two routing protocols with the increase in executable image and memory footprint. :-) Russ Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
In message 4e9f3e69.90...@isi.edu Joe Touch writes: On 10/19/2011 12:30 PM, Curtis Villamizar wrote: In message28269.1318994...@marajade.sandelman.ca Michael Richardson writes: Curtis == Curtis Villamizarcur...@occnc.com writes: Curtis A WiFi AP will not connect to another AP and wireless Curtis routers are typically AP by default. So if two wireless Curtis routers autoconfig to being AP and using open routing, then OUT OF THE BOX: not every device plugged into a home network have no prior configuration. For instance, someone bringing a newsed device to grandma's house. He who configures it needs to fix it. Or press the factory default button (if there is one). The example is two AP. Most AP can be restored to factory default with a button press. What happens if you have two of them and they're BOTH configured to boot as the master home access point? Master home access point? What is that? We are not talking about today's primitive NAT boxes that pretend to be routers. They either have a default route to the Internet or they don't. If they have a defailt route and they are at equal distance to that default route, then there are some arbitrary tie breakers. Worst case for AP might be if they are hard configed to the same channel and are very close to each other so they have about the same S/N and hosts can't decide which one to associate with, plus the interference with each other. In any case a press of the factory settings button should fix it. ... Curtis there is only a risk if something that is an WiFi client is Curtis also a configured to be a router. Yes, but we want to assume that at least one of these will be configured as a router as a default, which means we KNOW someone will turn on two of them We want to assume that *all* AP are configured as routers except the legacy ones that want to be a dumb bridge with NAT to one port. On BSD and I suspect Linux as well, the default for: net.inet.ip.forwarding net.inet6.ip6.forwarding are both zero. Right, but that cannot be the default for a homenet box. You are mixing the discussion of what we want in routers with what we don't want enabled by default in every *legacy* PC, toaster and coffee maker. If the coffee maker is a competent IPv6 router with extensions to let it autoconfig, then let it be a router. I really don't want my dumb old kitchen appliances trying to NAT for each other. But that new IPv6 espresso maker that knows how to act as a router - that would be OK. :-) You lost the context. You snipped out the statement I was replying to. A little too much trimming on the response. It happens. Joe Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] comments on draft-chown-homenet-arch-00
First of all I would like to thank the four authors for putting this draft together. It seems to be as a reasonable starting point. We have had quite a bit of good discussion on list, but not specifically about the drafts we have available. I've read this and have mostly nits about is there. That is best put in diffs. I think we can add a lot which is best not done as diffs. Below are unified diffs on the txt version indented an extra four spaces. The indenting should still be OK with SMTP line wrapping (still under 78). Annotation is not indented. [ to extract just the diffs grep -v '^ ' | sed 's/^//'. ] --- draft-chown-homenet-arch-00.txt 2011-09-21 11:34:00.0 -0700 +++ draft-chown-homenet-arch-00.chg 2011-10-13 10:20:04.0 -0700 @@ -121,12 +121,14 @@ networking technology in an increasingly broad range of devices and media. This evolution in scale and diversity sets requirements on IETF protocols. Some of these requirements relate to the need for - multiple subnets for private and guest networks, the introduction of + multiple subnets, for example for private and guest networks, + the introduction of IPv6, and the introduction of specialized networks for home automation and sensors. While advanced home networks have been built, most operate based on - IPv4, employ solutions that we would like to avoid such as network + IPv4, employ solutions that we would like to avoid such as cascaded + network address translation (NAT), or require expert assistance to set up. The architectural constructs in this document are focused on the problems to be solved when introducing IPv6 with a eye towards a Nit: Multiple subnets are needed for other reasons as well. Nit: IPv4 NAT is OK and needed in some cases. We want to avoid cascaded NAT. This may remove some of the objections to anti-NAT wording. @@ -183,13 +185,13 @@ routing and security policies. Documents that provide some more specific background and depth on - this topic include: [I-D.herbst-v6ops-cpeenhancements], + this topic include: [I-D.herbst-v6ops-cpeenhancements expired], [I-D.baker-fun-multi-router], and [I-D.baker-fun-routing-class]. In addition to routing, rather than NATing, between subnets, there are issues of when and how to extend mechanisms such as service discovery which currently rely on link-local addressing to limit - scope. + scope. [prefix scoped anycast?] The presence of a multiple segment, multi-router network implies that there is some kind of automatic routing mechanism in place. Nit: Just a note that the draft has expired. Comment/discussion: I agree that some mechanism is needed. This sound like anycast with some limitations. Some reasonable limitations might be the globally routable prefix of the home network or the prefix of the PI address. There is no prefix scoped anycast (AFAIK) and this is not a candidate for TTL based anycast. OTOH, routing information can provide a bounds on TTL and the anycast can ask for any type of resource within list of prefixes doing a second pruning at the application layer, or the anycast can be filtered at provider uplinks. @@ -353,7 +355,7 @@ |Router || Provider +---+---+| network | / -| Customer / + demarc #1 ---| Customer / | Internet connection / | +--++\ @@ -361,7 +363,7 @@ | Customer Edge | \ |Router | / +--++ / -| | End-User + demarc #2 ---| | End-User Local Network | | network(s) ---+-+---+--- \ | | \ The above two diffs add an indication of two potential homenet/provider demarcations to the figure. @@ -380,6 +382,35 @@ operation this arrangement is considered equivalent to the topology in Figure 1. + Two possible demarcation points are illustrated in Figure 1. The + samepossible demarcation points, while not shown, are applicable to + Figure 2 as well. The demarcation line indicates which party is + responsible for configuration or autoconfiguration. + + Demarcation
Re: [homenet] is this what homenet are trying to achieve? (was Re: Thoughts about routing
In message cakfn1sffxaa9snrc21lq8ltybrhn_1cmeo+euz7xr+oc3df...@mail.gmail.com Roger Jørgensen writes: snip alot of text from ongoing discussion I've been on my way to write this, most of all for myself, for a while so here we go... This is how _I_ understand most of the ongoing discussions and where we are going, our goal. It is not at all technical on the protocol level, it is a high-level view/design/scenario... I'll try to summarize how I understand homenet with breaking it down to three part/layers. 1.) uplink towards internet 2.) internal routing/mesh/something 3.) end-user facing connection (wireless/wired) See below. Added a few. about #1 - uplink towards internet I believe we can quite safely assume we have to support more than two uplinks from our homenet device, at least we need to support it. Probably a mix of wired and wireless, any mix really and any way. Those links need some protocol to make connection to it's other side (ISP/provider). That part is covered afaik but we might want to make them more advance on the routing side but not our biggest concern I would assume it would be useful in the zeroconf mindset for the uplink(s) to know if it's alone or not. One could be wired and one wireless toward the same provider. There are already providers selling that type of connection as a product, ADSL combined with a backup 3G link work like a charm. But of course, they've hidden the routing and linknet part behind a VPN/MPLS-alike system :) What should happen if the in-use uplink goes down, I guess it should back-off, tell the other hi, my uplink(s) are down, then pull back all of the prefixes it use and let the other uplink take over... somehow through some magic/undefined system:-) ... or maybe the uplink just tell layer #2, hi I'm down and let that part solve it? And another scenario, maybe not all of the uplinks are towards what we call Internet, maybe only one of them have the full view of Internet while the other two are toward other closed network? So we need some sort of routing here to... I do not except #1 as stated. 1. No built in assumptions about whether a router has an uplink port and if so, which port it is. a. there may temporarily be no uplink in the internal network. b. the router may be used as an internal router with one of more uplink elsewhere. c. the router may have one or more uplink, which does not rule out an uplink attached elsewhere in the same internal network. d. assumptions about uplinks may be learned (zero config) or configured. Note: a good rule would be if you are not sure you have an IPv6 uplink never give out a PD longer than /65. If a prefix is handed out (to you) that is /64 or shorter and globally routeable, assume it is an uplink to a provider. Note: at this point, no assumptions as to how this is accomplish. It is doable (my assertion, echoed by others, disputed by some, ... or maybe I'm echoing). about #2 - internal routing Can be the same box, or another, but a bit different tasks to be executed. The same here as for uplinks, there are quite likely to be more than one LAN. Guest network vs normal network are the two most common... Combined with two uplinks we are talking about the possibilities to have more than two prefixes in use (IPv6) and more than one NAT segments (LAN). Somehow this layer need to know where to send the traffic, or where not to send it. And if said uplink 1 goes down, then maybe that prefix need to be revoked and instead use the prefix from uplink 2 ? Not to forget the network some of us have, more than two LAN with routing and not NAT, three uplink (2 IPv6 and one IPv4), wireless, wired, wireless-bridge between wired network etc... we need to be able to manual overrule some options and add custom configuration. Tons of other problems here to but it's just routing :-) ... there is also the problem of any end-user equipment having both wired and wireless connection, multihoming really :-) But that really is for the next part to handle. No product sold as a router should do only bridging and NAT. That is a NAT appliance with bridging on the NATed side. We should be very clear about that. If it does not route, and it just does NAT, it is not a router. **That needs to be in an RFC.** Change from routing to allocation. Keep routing separate. #2 internal address allocation a. temporary addressing For both IPv4 and IPv6, a means is needed to start out with a globally non-routable prefix and subdelegate addressing, then establish temporary routing. For IPv6 a means of doing this is defined in IA_PD requests in DHCP6, but maybe not meeting all requirements. Ask neighbors for addresses and then delay with randomization in the delay before creating a fresh allocation. Hopefully except in
Re: [homenet] Thoughts about routing
In message 4e9a6657.70...@raszuk.net Robert Raszuk writes: Hi Fred, I think the point is that in your algorithm you stated this step: (3) It has to change its RID and start from the beginning. I would say (perhaps in line with Curtis comment) that this step is unrealistic. RID for many reasons (for example mpls-te) is hard configured in link state IGPs. If it is hard configured, then is has to be configured correctly. Otherwise you have a conflict among two configured RID, then you have a persistent non-working network. If a autoconfig guy comes along and stomps on it, then only the autoconfig guy backs off. Worse - some vendors - do base on this their very cool hack to forward v6 traffic over v4 TE LSPs. So I think statement that router has to change it's RID is operationally non starter. So you are saying that a vendor has a hack (private undocumented extension might be the market-speak) that is not backwards compatible to other implementations *of a full standard* and we can't create a backwards compatible extension because it would interfere with the hack? (which you think is a very cool extension?) Cheers, R. On Oct 15, 2011, at 6:35 PM, Curtis Villamizar wrote: All adjacencies have to go down to change router-id. The other end of the adjacency will withdraw its side of the adjacency. well, yes, and if I change my routerid, all adjacencies will go down. Not sure what the point here is... Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing
In message 0651f29f-c816-4a23-bd6f-c791ce89b...@cisco.com Fred Baker writes: On Oct 13, 2011, at 6:09 PM, Lorenzo Colitti wrote: On Mon, Oct 10, 2011 at 14:16, Curtis Villamizar cur...@occnc.com wrote: Random number selection for router-id and this sort of recovery would solve the zero config OSPF issue related to router-id selection. Not yet solved in existing zospf draft (afaik) but solvable. zOSPF says what do do in the case of collisions if the router with duplicate ID is on the same link, but not if it is elsewhere. However, I think it can be made to work like this: 1. On startup, choose the router ID you had on last boot (if available) or a random number. 2. Start OSPF with this router ID. 3. If you see a hello packet from a neighbour with your own router ID, you have a collision on the local link. Change it and back off. 4. If you see a router LSA listing you as a neighbour, but the router ID that originated this LSA is not a neighbour of yours, you have a duplicate router ID. Change it and back off. Are there any cases this does not cover? On number 3, there is a race condition. If the router took some time to boot, this takes care of itself; if this is a flash restart (OSPF started up within one or two HELLO intervals of going down) there is some possibility that the neighbor simply has some old state. Note that the OSPF Spec has the router initially send a HELLO and then start looking for HELLOs from peers that announce it; it would be good for OSPF to instead wait for one HELLO interval so that it sees the HELLOs from other routers on the LAN before announcing itself if it's not sure about the uniqueness of its RID. On number 4, that would be a Router LSA or Network LSA; in a LAN subnet, the RIDs of the routers in the subnet are in the Network LSA. An ISIS LSPDU fragment is *really big*. To avoid having to check the whole thing to see if it changed, ISIS routers checksum relevant parts of the LSPDU and compare to the checksum to the prior advertisements. That is how they tell if they might have a new LSPDU fragement and might have to reflood it and update the LSDB. Brute force compare works too but just takes a lot longer. OSPF LSA are smaller but more numerous, but there is no reason that the LSA can't be checksumed. Any OSPF router should know what LSA it originated. If an LSA doesn't resemble anything it originated, pick another router-id. If it was a stale LSA, it does no long term harm to pick a new LSA after a reboot. Every LSA has Advertising Router starting at byte 8 for both OSPFv2 or OSPFv3. The packet formats are in Appendix A in both rfc2328 and rfc5340. If Advertising Router equals me and this LSA looks bogus, there is likely to be a router-id collision. Or it could be a stale LSA from a fast reboot, but so what, just pick another router-id and start over. As to what to do if there is a collision, I'm not sure. zOSPF says what you and your neighbours should do if the colliding router is on your link, but I don't know if that's enough if the colliding router is elsewhere. Any OSPF experts know the answer to this? What the router needs to do is (1) NOT send an LSA using the RID into the LS database, as this will confuse everyone else (2) it would be good etiquette to announce one more HELLO in which it lists no neighbors so that all of its neighbors, and especially the DR, think it's going down. That way it doesn't get into the Network LSA, or if it already did, it will be removed. (3) It has to change its RID and start from the beginning. All adjacencies have to go down to change router-id. The other end of the adjacency will withdraw its side of the adjacency. If the other user of the router-id is not adjacent, the problem will be discovered after the initial hello handshake and during the database exchange, but it should occur before the first adjacency is completely up. The adjacency isn't up until the database exchange is complete. Any LSA that were advertised will be seen as stale by the former user of that router-id. They will be withdrawn. The good news is that it now has some subset of the LSA Database, so the second exchange will be somewhat quicker, and it already knows who the DR is in at least that subnet. Random number is a good description of the source for the RID. MAC Addresses and equipment serial numbers tend to be reasonable seeds, and a router will usually have more than one such. If it used one MAC address and that didn't play, it might try another. If push comes to shove, a call to random() is probably in order. Did anyone read my prior email in which I cited the RFCs and section numbers and quoted the relevant text? If not, look for: Message-Id: 201110131811.p9dibe9i021...@gateway.ipv6.occnc.com To: Acee Lindem acee.lin...@ericsson.com cc: cur...@occnc.com cur...@occnc.com, Russ White ru...@riw.us, homenet@ietf.org homenet
Re: [homenet] Thoughts about routing
In message 1e8bbe2e-357a-4681-bb84-4e694afd9...@ericsson.com Acee Lindem writes: One assumption could be that a legacy router would not support auto-config and, if deployed, would have to be configured with a unique Router ID (as they are today). Got that. Don't use a non-configured router-id if you don't support this ability to back off. (Routers today don't pick a random router-id and they shouldn't unless they can backoff). Thanks, Acee The key uncertainty is the effect of a collision on a legacy router. This looks like it is covered. (indentation changed) [RFC2328] 13.4. Receiving self-originated LSAs It is a common occurrence for a router to receive self- originated LSAs via the flooding procedure. A self-originated LSA is detected when either 1) the LSA's Advertising Router is equal to the router's own Router ID or 2) the LSA is a network- LSA and its Link State ID is equal to one of the router's own IP interface addresses. However, if the received self-originated LSA is newer than the last instance that the router actually originated, the router must take special action. The reception of such an LSA indicates that there are LSAs in the routing domain that were originated by the router before the last time it was restarted. In most cases, the router must then advance the LSA's LS sequence number one past the received LS sequence number, and originate a new instance of the LSA. [...] In all these cases, instead of updating the LSA, the LSA should be flushed from the routing domain by incrementing the received LSA's LS age to MaxAge and reflooding (see Section 14.1). [RFC5340] 4.5.1. Receiving Link State Update Packets [...] In IPv4, eight steps are executed for each LSA, as described in Section 13 of [OSPFV2]. For IPv6, all the steps are the same, except that Steps 2 and 3 are modified as follows: [stub or nssa or reserved scope changes] It seems then that if the auto-config router picks a new router-id, the legacy router will correct any damage. Perhaps the legacy router will do this for the wrong reasons (collisions, not stale leftovers from a restart elsewhere), but it seems like it will take action to fix it. Acee - should this move to OSPF? Others - No cross posting please. Curtis On Oct 12, 2011, at 10:46 PM, Curtis Villamizar wrote: In message 4e95836d.4020...@riw.us Russ White writes: Russ You need a unique identifier at the equipment level for Russ anything you intend to auto-configure --autoconfiguring Russ uniqueness is a very hard, probably impossible, problem on a Russ global scale. So we need to count on this one thing, no matter Russ what else we might need to back in to. Russ Now, it might be possible to some hash over a GPS location for Russ a base, and then add on MAC addresses, or some such, but We've assumed a unique MAC, which is 48 bits long. But OSPF router-id is 32 bits.What is the likelyhood of a collision in the bottom 32-bits of the MAC? Ah, I see the problem... There is a pretty high likelihood of a collision, actually, at least as long as you use multiple vendors in your home network. It's bound to happen to someone, someplace. So, a suggestion to resolve this: 1. Use the lower 32 bits of one of the mac addresses on the box as the initial id. 2. Add a new field to the router capabilities that carries the full 48 bit mac address, or even some munged together longer id, based on multiple mac addresses on the device, or some such. Not backwards compatible. The older OSPF routers will see only the non-unique 32 bits and the network won't work. 3. During initial setup, if you receive a capability that appears to be from yourself, you open this secondary id section to find out if it's really you, or someone else who happens to have the same 32 bit id. 4. If it's really you, discard the packet. 5. If it's not really you, and if the other router's large id is lower than yours, choose another mac address from which to take your local id, and restart your ospf process. 6. If it's not really you, and the other router's large id is higher than yours, then send a router capabilities LSA unicast to this other router, so the other router knows to change its id. I don't think IS-IS would have this problem. :-) Russ If the other router doesn't implement the extension you've described, the network is hosed forever. If you have more than one link you should receive the LSA (or LSPDU) that you advertised. If you have one link, you won't. If you receive a LSA (or LSPDU) that clearly you didn't advertise, then you have a collision. *Both* routers should pick a new router-id if this condition is detected and they implement this extension. Don't even bother using a MAC address
Re: [homenet] security question for zeroconf stuff inside the homenet...
In message 8031f94c-66bf-4748-aa97-5efa12bb8...@fugue.com Ted Lemon writes: If you autoconfigure a routing topology, you have to make sure that you don't accidentally autoconfigure it to include routers that weren't intended to have been included. The concern is not for grandma running Windows 98, and the whole hard shell/gooey center debate is completely beside the point. You've said what the problem *isn't*, so what *is* the problem on a homenet? Surely the provider is not going to accept a unauthenticated auto-config hello request and start peering, nor will it accept a hello from a legacy router configured with router-id and a be adjacent to anything policy. If the electric meter wants to be a router with a slow link on the power line, then it needs to act like a provider router, but perhaps only advertising reachability to the electric utility, not the whole Internet. The more specific prefix (than default) should get the attention of the water heater if it has to try to reach the electric utility. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet strawman slides
In message 2aa0f4ae-cade-4dd3-9701-fc0671712...@townsley.net Mark Townsley writes: On Oct 12, 2011, at 6:23 PM, james woodyatt wrote: 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. Every IPv4 home router I have ever seen hands out RFC 1918 space regardless of whether an ISP connection is active. This is needed, if nothing else, to manage the router with the classic IPv4 literal in a web browser (yes, this could be done with link-local, but that's not something you can hard-code in documentation or a sticker on the side of the box). For IPv4, routes can be installed for non-local link-local addresses or ULA prefixes can be used if no address is available. The practice of using 192.168.1.1 should be changed. The change could be as simple as a DNS mapping of local-router. to the link local addres. A DHCP host query would get an offer of a DNS server which would respond with a DNS entry for local-router. The dot is significant though if omitted the domain search list would be used with the last entry presumed blank. As long as there is no local-router. TLD glogally defined this should be OK. A user with multiple routers on the subnet can just paste the link-local address in place. Maybe routers can look for others and offer a local-router-N. for each other router detected. Then http://local-router.; or http://local-router-N.; can be used if the user does need to do any config. There could also be some improvement on the common practice of allowing a default password on any port except the designated uplink. In an auto-config router this would never change. Perhaps this could be enabled only 10 seconds or so after power up if the factory default password is in place, at least limiting the exposure. This could fit in the manual and maybe even on a sticker. But yes, IPv4 must hand out a PI address if it has nothing else to hand out. 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. Update or just advertise the new global prefix alongside the ULA? - Mark I meant update in the context of refreshing the IA_PD request at the provider DHCP server that handed it out the last time the demand circuit was up. If the prefix was held while the demand circuit was unused and down, then no change is needed on the homenet side when the demand circuit comes back up. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
In message 4e96ce51.7020...@riw.us Russ White writes: Should the applications be insecure and rely on a firewall? (Microsoft advocated this in the 1990s and it has stuck to a large extent). Or should the network be open and the applications secure? I'm strongly with you on this. The applications should take care of any security that is necessary *for that application*. In other words, we should abandon door locks and make certain that anything you don't want stolen is individually secured --because only the device manufacturer could ever know how valuable it is, and how best to prevent it being stolen? Following that analogy, the door locks built my certain OS vendors are both flimsy and easily picked. And we should not enable tftp and point it at the root directory and hope that some smart network appliance will somehow firewall us. In your own words: No. No. No. Security is layered in the physical world, and it should be layered in the network, as well. That I argue for a default domain based posture, where all machines within a given domain are all fully reachable, but those outside the domain are not reachable unless specific actions are taken to make them reachable, doesn't mean I don't think individual computers need security at all, or that all security should rely on the firewall. All security must be on the firewall or in the applications is a false dichotomy. Ideally the firewall should be unnecessary. In some cases a firewall is out of the question. For example, a router cannot rely on sitting behind a firewall. That is not to say that packet filters at the border don't serve as a valuable denial of service protection against pure traffic based attacks. Firewalls more often get in the way than do any good. They also give a false sense of security which results in the occasional our LAN is currently swamped as a result of the latest virus run amuck on our LAN coming from IT. Security is not a layer-2 function. Security is an application function. You had it right the first time. Key exchanges and certificates are not layer-2 functions. Security is an application function, yes. Security is also a network function, and security is a machine level function. All of these have a role to play in security. :-) Russ The operations staff for the T3-NSFNET had no firewall and was security audited by some of the best in the field. Of course we did not allow the use of a PC with Windows in operations. No such thing could sit on the same subnet. Another division in ANS that relied on a firewall was the only part of the company that even had to have all computers taken down and scrubbed before they could be used again. [Requirement at that time of having certain government customers]. Every computer had to be physically removed, rebooted from other media, backed up, reinstalled, user files restored from a backup prior to the breach, and returned to the rack or the user's desk. Users had to fetch any lost work from the backups and were supposed to insure that no changes where made to recovered source code. Sound painful and costly? It was! Network protection of insecure host applications is false security. It takes just one host breach to compromise the whole internal network. I've seen it first hand many times. [not quite first hand since my computers never relied on a firewall for security but a few times on the corporate LAN they were sitting on.] IPSEC also got it wrong. The application really is the right place for security. :-) btw- Anti-virus software is a cruel hoax. [that someone makes money on] :-) It is entirely possible that the same computer has pictures of Grandma that I'm OK with you seeing and has a printer hanging off it that I don't want anyone in the world to be able to print on. Same MAC address. So that can't be a layer-2 function. And port filtering at a firewall is a lame excuse for security. The bug in relying on a firewall in an enterprise (a little less so for a home) is that once any one user downloads malware, that malware has access to everthing behind the firewall largely because of the assumption that security is not needed because there is a firewall. Lets not enshine the dumbest practices of the IT world. I think homenet should focus on L3. (and be clear on what it expects from the other layers with regards to security). cheers, Ole Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing - trends
Off list. In message 4e96d145.5090...@riw.us Russ White writes: At various jobs I pulled 10base2 coax, then 10base5 coax, then twisted pair. [Well someone pulled it, but not me.] Anyone remember vampire taps in 10base2? What a reliability headache! Pulled from cable hanging in a plenum in a secure building... Because there was no way to get cable floor to floor other than through that single shaft. For a Xerox Star system. Then there was the token bus for the little Novell network over in legal --another disaster. blech I managed to avoid token ring and novell. Back on topic: I do think we should consider OSPF (not so keen on ISIS, but OK) and should not rule out OLSRv2 or other LLN related work and MANET work (though I'm far from an expert on LLN or MANET). IS-IS is easier to get to zero config, and it's actually simpler in operation... Which is why I brought it up. :-) I've used both. Why do you think ISIS is simpler in operation? Because people love to deal with NSAPs? We will have to extend OSPF to make zero config possible. The extensions should be completely backwards compatible if at all possible. Yes, I agree... Or we need w new wired/wireless protocol that jumps both worlds, and would actually be acceptable and implemented by a large number of vendors. But that's another entire problem space... We agree on something. That's good. :-) The clueless vendor problem space is a tough one. :-) Russ Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing
In message 14861.1318513...@marajade.sandelman.ca Michael Richardson writes: Mark == Mark Andrews ma...@isc.org writes: Or you solve the time problem some other way... Batteries die too... Jim Mark Indeed. It should be a user servicable part. Mark As to solving it other way, leap of faith springs to mind. DHCP has an NTP server option. Does IP6CP? If you are trying to validate keys or certificates or proteocol extensions that require knowing the time of day, then using the DHCP supplied NTP server might not be a great idea. I'm not fond of protocols that rely on time or monotonically increasing reboot counts and have no fallback. I advocated in OSPF discussions relevant to KARP (to no avail) having at least a fallback to a mechanism in which time of day or reboot count was not significant. This means no certificate expiration check is possible for the fallback but its better than no connectivity. The lack of certificate expiration can be compensated for by creating an explicit revokation after the key expires and storing that. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] time service and DNSSEC
In message 17165.1318514...@marajade.sandelman.ca Michael Richardson writes: Curtis == Curtis Villamizar cur...@occnc.com writes: While talking about hardware. These these devices all need a battery backed clock or all the crypto will be broken. Curtis Having a clock is not hard but I don't think your statement Curtis is true. Curtis Some crypto does not require time, but rather just entropy Curtis (a nonce or challenge). For crypto that does require time Curtis the former can be a bootstrap of sorts, possibly to get ntp Curtis going if very accurate time is needed (for some reason). Curtis, Mark, as a DNSSEC implementer knows of what he speaks. DNSSEC requires time. Not to the second or even minute, but at least hour. DNSSEC is a core protocol at this point, and we need to be aware of it. It doesn't matter today, because we have a broken home DNS system, but that's within homenet to fix. Bootstraping time enough to get DNSSEC to work is important. I was thinking routing protocols and KARP. We are talking about routers and relying on DNS to get routing up is always a really bad idea. Relying on NTP to get routing up is also a bad idea. Neither KARP, as defined, or DNSSEC, are candidates for zero configuration. If the user can configure KARP and DNSSEC they are perfectly capable of using a backdoor, like ssh, to set the time of day after a reboot that lost time-of-day. Sorry, but I lost track of why this is an issue for homenet. What zero config crypto are we talking about that may care if it loses time of day? Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
