Re: [homenet] Please review the No IPv4 draft
I've not had time to review the whole thread, so apologies if this has been covered elsewhere. It occurs to me that one scenario that needs to considered is when a machine moves from a network which wants to suppress IPv4 to one which is still providing IPv4 (possibly only IPV4). To make that work implies that the DHCPv4 client should still exist in the IPv4-suppressed state, doing nothing except looking for loss of ethernet carrier or change of wireless ESSID, at which time is should try again to get a DHCPv4 lease. However this is implemented, just killing the DHCP client is not going to cut it. My personal feeling is that suppressing IPv4 should be a a DHCPv4 function, that keeps the go-into-hibernation transition solely in the DHCPv4 code, it also means the when IPv4 support finally goes, so does the transition mechanism. Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] RFC: dhcpv4 to slaac DNS naming scheme
On 15/02/14 10:35, Lorenzo Colitti wrote: On Sat, Feb 15, 2014 at 6:23 PM, Simon Kelley si...@thekelleys.org.uk mailto:si...@thekelleys.org.uk wrote: This technique is useful for all the _existing_ systems that only do EUI64 SLAAC, I don't think it's something we should do going forward. Which ones are those, though? I mean - we can certainly write this up as is, but if it doesn't work on Windows, Mac OS, or iOS, then... how much use will it be in the real world? The obvious answer is Android, which is what it was originally implemented for. I think the three platforms you mention have have DHCPv6 support, Android doesn't, or at least didn't: I'm not sure about the latest releases. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Wide Area DNS-Based Service Discovery walkthrough
On 14/03/13 05:21, Stuart Cheshire wrote: There's been some discussion about service discovery. Anyone who prints wirelessly from their iPhone or iPad without typing in an IP address is using service discovery. Anyone who’s watched video on a web page on their iPad, and then tapped the screen to transfer the video playback to their television, without typing in its IP address, is using service discovery. Anyone who’s streamed music from their iPhone to their wireless AirPlay speakers, or controlled their TiVo from its iPad app, or shown a slide show from their phone on a friend's television screen, or given a university lecture by beaming their presentation wirelessly from their laptop to the video projector, all without typing in any names or IP addresses, has been using service discovery. This is all commonly done today, but generally only on the local link. We'd like similar ease of use in larger networks too. I recently submitted this draft: http://www.ietf.org/id/draft-cheshire-mdnsext-hybrid-01.txt snip very illuminating details Here at IETF, the records are added to the DNS manually by our capable network volunteers. The idea of the Hybrid Proxy is to populate the DNS namespace automatically, making Wide Area DNS-Based Service Discovery available to a broader community of users. I'm concerned that that basis of this whole discovery mechanism is the domain name DHCP option. The service discovery mechanism has now migrated to the DNS, so all services are potentially discoverable from anywhere; that's good. But the concept of what's local is now hung exclusively on the value of DHCP option 15. DHCP option 15 most be one of the most overloaded and least well characterised of any DHCP options. Lots of homenet-type installations will have it set to .lan or something similar. Some will set it to .local only to discover that the .local TLD has been usurped. It's used frequently as substitute for the domain name search list option but concatentating more than one domain with spaces, for clients which don't support the later option. It's somewhat succeeded by the FQDN option, and therefore not supplied. DHCPv6 doesn't have, AFAIR an equivalent, only the FQDN option. Now, we want to overload with yet another meaning. Is that wise? Wouldn't defining a new option be better? Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On 26/02/13 15:07, Michael Thomas wrote: On 02/25/2013 11:52 PM, Simon Kelley wrote: If I got your problem statement right, I'd argue that there are, essentially, two problems here: 1) Learning the IPv6 addresses in use 2) Updating the DNS accordingly Dnsmasq does both of these for internal DNS, it's just an extension of what it has always done in IPv4 land. There's a new test release that does the same for external DNS, by acting as the authoritative server for a zone, and/or providing zone transfer to other authoritative servers. I'm not understanding: what is the name that it associates with the address? A synthesized one like ISP's often do with forward map addresses in their dynamic pool? Either the name that the host provides in a DHCP hostname or FQDN option, or a name associated with the host in the dnsmasq configuration. Most DHCP clients provide the hostname in their DHCP requests these days. Dnsmasq configuration allows associating a name with a MAC address or client-id. Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On 26/02/13 18:21, Michael Thomas wrote: On 02/26/2013 10:15 AM, Simon Kelley wrote: On 26/02/13 15:07, Michael Thomas wrote: On 02/25/2013 11:52 PM, Simon Kelley wrote: If I got your problem statement right, I'd argue that there are, essentially, two problems here: 1) Learning the IPv6 addresses in use 2) Updating the DNS accordingly Dnsmasq does both of these for internal DNS, it's just an extension of what it has always done in IPv4 land. There's a new test release that does the same for external DNS, by acting as the authoritative server for a zone, and/or providing zone transfer to other authoritative servers. I'm not understanding: what is the name that it associates with the address? A synthesized one like ISP's often do with forward map addresses in their dynamic pool? Either the name that the host provides in a DHCP hostname or FQDN option, or a name associated with the host in the dnsmasq configuration. Most DHCP clients provide the hostname in their DHCP requests these days. Dnsmasq configuration allows associating a name with a MAC address or client-id. Ah, ok. But that wouldn't work in a SLAAC environment unless it did a DHCP INFORM, right? Hosts don't do that generally, right? It works in a SLAAC environment where the host _also_ does DHCPv4, which is where we came in... Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On 26/02/13 06:14, Fernando Gont wrote: Hi, Simon, On 02/23/2013 03:02 PM, Simon Kelley wrote: On 23/02/13 17:56, Teemu Savolainen wrote: And this works with hosts that use IPv6 privacy addresses and not have IIDs derived from MAC? If they have only privacy addresses, it doesn't work. If they have both a SLAAC address and a privacy address, and use the privacy address when initiating connections (for privacy), but accept connections to the SLAAC address, then it still works. But.. if you're learning the IPv6 addresses based on the assumption that they are the traditional SLAAC addresses (that embed IEEE identifiers), you'd be missing IPv6 addresses of Windows nodes (which do not generate IIDs according to traditional SLAAC), any nodes using CGAs, etc. On my network, the Windows nodes use stateful DHCPv6. I don't see this technique as a universal panacea or something to necessarily rely on going forward, but it does make naming work _for_existing_deployed_systems. It works, for instance, with hundreds of millions of existing Android phones and tablets, 99.99% of which will never be upgraded. Simon. Cheers, ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On 23/02/13 23:38, Dave Taht wrote: Simon Kelly took what we had in cerowrt, and improved it substantially, however there is still some stuff that is less than desirable, notably, the DNS TTL is presently set to 0 in the dnsmasq implementation This isn't quite accurate. Replies with cached data from forwarded queries of course get the TTL from upstream, reduced by the time the data has been cached. Replies with 0 TTL are answers to queries from internal hosts (ie from hosts on the local net) where the data in also local (ie stuff from /etc/hosts, other configuration or DHCP leases). The rationale is that re-doing the query is very cheap for these hosts, and there is no other good value for TTL. DHCP lease time is not a good value. My laptop can have a DHCP lease with days left to run on my wireless subnet: if I plug in the wired network port, the name will be transfered to the new lease on the wired subnet, and I don't want to wait for days for all the hosts on the net to catch up with the new address. For queries _not_ from the internal hosts (i.e. the new auth functionality) the TTL in the replies currently defaults to 600, and is configurable. These replies are only ever local data, dnsmasq will never forward-upstream queries from the wider net, to avoid DNS amplification attacks. Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On 23/02/13 17:56, Teemu Savolainen wrote: And this works with hosts that use IPv6 privacy addresses and not have IIDs derived from MAC? If they have only privacy addresses, it doesn't work. If they have both a SLAAC address and a privacy address, and use the privacy address when initiating connections (for privacy), but accept connections to the SLAAC address, then it still works. Simon. From: Simon Kelley mailto:si...@thekelleys.org.uk Sent: 22.2.2013 17:54 To: Ted Lemon mailto:mel...@fugue.com Cc: homenet@ietf.org mailto:homenet@ietf.org; David Lamparter mailto:equi...@diac24.net Subject: Re: [homenet] NPTv6-only home networks On 22/02/13 14:50, Ted Lemon wrote: On Feb 22, 2013, at 8:24 AM, Simon Kelley si...@thekelleys.org.uk wrote: It works as well for clients which do DHCPv4 and SLAAC. IPv6-only hosts would have to do stateful DHCPv6, but the DHCPv4 and SLAAC model covers an awful lot of currently-deployed clients. So dnsmasq is noticing that the IPv4 and IPv6 hosts are the same host using the MAC address or something, and then coordinating the DNS registration? As the DHCPv4 state machine moves to lease complete it spits a (MAC address, hostname, broadcast domain) tuple over to the IPv6 side. The broadcast domain plus configuration yields a list of prefixes, and the MAC address gets turned into a SLAAC host-identifier. The two make a set of putative addresses. The state machine then sends an ICMP6 echo request to each putative address and if it responds then that address is added as an record with the hostname. There are some implementation details involving timeouts and retries and sending speculative router advertisements to ensure that a new-on-the-network host is ready to reply to the pings. The practice is that it always works, even a smartphone moving slowly into a dodgy Wifi network. If the client can get a DHPCv4 lease, the IPv6 SLAAC address gets a name too. Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On 22/02/13 12:30, Ted Lemon wrote: On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti lore...@google.com wrote: I think the issue that Michael imagines NPTv6 will address is the transition period, when the washing machine has two IP addresses, and the DNS may not have the new address, or may have both addresses, and he's hoping the gateway will somehow bandage this up. However, the gateway's ability to bandage this up is more imagined than real, and we might as well just fix the underlying problem. The current development release of dnsmasq can act as an authoritative DNS server populated with all hosts on a homenet which it knows about from DHCP. Delegate your domain to it, and ensure that the TTL configured for DNS is smaller than the deprecated lifetime of addresses, and this problem should never arise. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On 22/02/13 13:07, David Lamparter wrote: On Fri, Feb 22, 2013 at 01:00:48PM +, Simon Kelley wrote: On 22/02/13 12:30, Ted Lemon wrote: On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti lore...@google.com wrote: I think the issue that Michael imagines NPTv6 will address is the transition period, when the washing machine has two IP addresses, and the DNS may not have the new address, or may have both addresses, and he's hoping the gateway will somehow bandage this up. However, the gateway's ability to bandage this up is more imagined than real, and we might as well just fix the underlying problem. The current development release of dnsmasq can act as an authoritative DNS server populated with all hosts on a homenet which it knows about from DHCP. Delegate your domain to it, and ensure that the TTL configured for DNS is smaller than the deprecated lifetime of addresses, and this problem should never arise. This only works with stateful DHCPv6 though? It works as well for clients which do DHCPv4 and SLAAC. IPv6-only hosts would have to do stateful DHCPv6, but the DHCPv4 and SLAAC model covers an awful lot of currently-deployed clients. The IPv4 addresses can be RFC1918, the DHCPv4 lease is used to give dnsmasq the MAC address and name of a client. The authoritative DNS module is configurable to expose global IPv6 addresses and hide RFC1918 IPv4 addresses. Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On 22/02/13 14:50, Ted Lemon wrote: On Feb 22, 2013, at 8:24 AM, Simon Kelley si...@thekelleys.org.uk wrote: It works as well for clients which do DHCPv4 and SLAAC. IPv6-only hosts would have to do stateful DHCPv6, but the DHCPv4 and SLAAC model covers an awful lot of currently-deployed clients. So dnsmasq is noticing that the IPv4 and IPv6 hosts are the same host using the MAC address or something, and then coordinating the DNS registration? As the DHCPv4 state machine moves to lease complete it spits a (MAC address, hostname, broadcast domain) tuple over to the IPv6 side. The broadcast domain plus configuration yields a list of prefixes, and the MAC address gets turned into a SLAAC host-identifier. The two make a set of putative addresses. The state machine then sends an ICMP6 echo request to each putative address and if it responds then that address is added as an record with the hostname. There are some implementation details involving timeouts and retries and sending speculative router advertisements to ensure that a new-on-the-network host is ready to reply to the pings. The practice is that it always works, even a smartphone moving slowly into a dodgy Wifi network. If the client can get a DHPCv4 lease, the IPv6 SLAAC address gets a name too. Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On 22/02/13 19:48, Ted Lemon wrote: On Feb 22, 2013, at 10:53 AM, Simon Kelley si...@thekelleys.org.uk wrote: The practice is that it always works, even a smartphone moving slowly into a dodgy Wifi network. If the client can get a DHPCv4 lease, the IPv6 SLAAC address gets a name too. That is _very_ cool. Nice work! I make no claims for the invention, only the implementation. I'm aware of it being independently invented at least twice, involving at least three different people. Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Robustness in Homenet. (triggered by the DHCP-PD discussion).
On 14/11/12 12:08, Teco Boot wrote: The one-and-only DHCP server knows about all the prefixes delegated from the ISP and the relays know which particular prefix has been given to the local router by the routing protocol or AHCP. I don't like a single DHCP server for multi-homed sites. This introduces unneeded complexity, it needs merging of information from multiple sources. This is completely incompatible with what MIF is doing (multiple provisioning domains). It also introduces an unneeded single point of failure. Multi-homing could be used for redundancy. Let's use a DHCP server for each ISP. In cases where a single CPE router connects to multiple ISPs, it can take two approaches: running multiple DHCP server instances, one for each ISP. Or perform the problematic integration. BRDP takes the per provisioning domain approach, where each provisioning domain is presented with a border router address (generated form provided prefix), with prefix length. Problem solved :-). OK. This raises some questions about DHCPv6 to which I don't know the answers. I hope Ted or someone else who was involved in the standard can answer. Simplest case first. Client and server on same link (in the RFC3315 definition of link) the server has an interface on the link which has multiple addresses with different prefixes, and it is configured to assign addresses on each of those prefixes. The client is unconfigured except for a link-local address. How does the client create a SOLICIT message which causes the server to reply with an ADVERTISE which offers the client an address with each of the prefixes ? The client doesn't know how many prefixes are available. Next case. The same as above but the SOLICIT transits via a relay. The relay can only insert one link address in the encapsulation, does the server have to know which prefixes share links so that it can determine which other prefixes are on the same link and reduce the problem to the case above? Next case. This speaks to Teco's suggestion. The same link with multiple prefixes, directly connected to servers, but now each prefix is handled by a different DHCP server. The client multicasts SOLICIT to all the DHCP servers. How does it collect all the addresses for different prefixes? Final case. Multiple DHCP server, all behind a relay. The relay has to be configured to unicast to each server in turn? Knowing the answers to these questions would be really useful at this point. Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Robustness in Homenet. (triggered by the DHCP-PD discussion).
On 14/11/12 16:24, Jim Gettys wrote: Please, let's not OD on DHCP in this thread: while I was making a point about DHCP, I was really making a more general point about robustness in homenet, and how to judge various proposals, more than specifically attacking recursive DHCP-PD as a concept. Similarly, I think as another goal we have to accept easy debuggability as a goal. We need to know if a router is expected to function, and you should be able to easily see if the router is functioning *and* if can talk to its border routers and the rest of the Internet. One of the things I like about CeroWrt is that I can *always* talk to the router and from there I have a chance to figure out if it is able to talk to the rest of the home network, and the world (e.g. by seeing that I've got an IPv6 network delegation). Today, since we have to presume that you need a IPv4 address, this implies running a DHCP server on each ^^ router: in the long run, it's less than clear to me that this is desirable. But one way or the other, I've got to be able to connect and talk to the router to be able to debug it, preferably from both upstream and downstream directions. The CeroWrt router I'm debugging doesn't fate share with other routers to the point that you have no place to stand initially. I agree with this, except the underlined section: DHCP-relay is a standard technique for DHCPv4. Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] prefix assignment on home networks
On 13/11/12 18:33, Randy Turner wrote: Hi All, I've been away from the list for awhile, and am trying to catch up -- is there a reference or quick explanation as to why a /64 assigned to a home network is considered to be potentially constrained somehow ? Because no IPv6 network can be smaller than /64 and have stateless autoconfiguration work. To have routed subnets in the homenet requires one /64 prefix per subnet, and a /64 prefix cannot be subnetted - it is already the smallest legal subnet. Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Robustness in Homenet. (triggered by the DHCP-PD discussion).
On 13/11/12 20:48, Victor Kuarsingh wrote: On Tue, Nov 13, 2012 at 3:19 PM, Simon Kelleysi...@thekelleys.org.ukwrote: Given that hosts are going to want to talk RA or DHCPv6, at least initially, one option down this route has the flood include the unicast address of a single, centralised DHCPv6 server, and routers run DHCP-relay agents which forward to that address. That gives you DHCPv6 functionality without recursive-PD complications. It also eliminates the problems of distributing the available prefixes as they traverse PD chains. The one-and-only DHCP server knows about all the prefixes delegated from the ISP and the relays know which particular prefix has been given to the local router by the routing protocol or AHCP. I assume in your model, hosts on the various subnets will then have access to a centralized DHCPv6 server and other hosts can still use SLACC (which is connected to ::/64s on the local attached router's interface). Would the internal routers also get the ::/64 prefixes from the central DHCPv6 server (assume so)? If yes, would they grab a PD (with hint) for a range large enough to cover all of its' interfaces? This part of the scheme is still wooly in the extreme, but my thinking is that DHCP-PD would _not_ be involved. The centralized server would be a DHCP-PD _client_ and get a set of prefixes from the ISP(s), but the distribution of those prefixes over the routers would be a side-effect of whatever configuration system generates the routing tables and spanning-tree for the homenet. I think I understood the OSPF guys at IETF as saying that OSPF could do this, and I think I understand Dave as saying that AHCP can do it. More details of either or both schemes would be very interesting to hear. Cheers, Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] regarding recursive DHCPv6-PD (and architecture document)
On 08/11/12 21:44, Ted Lemon wrote: On Nov 8, 2012, at 4:40 PM, Andrew McGregor andrewm...@gmail.com wrote: I see no reason not to do this... we'd have to have just about as much information to bridge successfully, and a few hundred routes is no big deal. +1 I realize that I've been arguing for a different solution, but I agree that this is better. For the stragglers, is this backwards compatible with existing devices? Will my Android phone, which expects to do DHCPv4 and SLAAC in one or more IPv6 /64s, connect unmodified to such a network? Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DHCP PD for homenets.
On 07/11/12 15:46, Ted Lemon wrote: I think the disconnect here is that people are thinking the routers to which prefixes are delegated need to themselves be delegating routers, but this is incorrect. What they need to do is _relay_ prefix delegation requests to the delegating router from which they got their own delegation. ... and once the delegating routers are relaying DHCP-PD requests, they can also relay DHCP address-lease requests to the DHCP server in the CPE router. This puts all the information about DHCP leases and associated names in one place, and greatly simplifies the naming problem. Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DHCP PD for homenets.
On 07/11/12 18:21, David Lamparter wrote: On Wed, Nov 07, 2012 at 06:03:52PM +, Simon Kelley wrote: On 07/11/12 15:46, Ted Lemon wrote: I think the disconnect here is that people are thinking the routers to which prefixes are delegated need to themselves be delegating routers, but this is incorrect. What they need to do is _relay_ prefix delegation requests to the delegating router from which they got their own delegation. ... and once the delegating routers are relaying DHCP-PD requests, they can also relay DHCP address-lease requests to the DHCP server in the CPE router. This puts all the information about DHCP leases and associated names in one place, and greatly simplifies the naming problem. This really falls apart when I'm using 2 ISPs with 2 exit routers. a-k-a, Where's up? and be put back together by noting that 2 exit routers doesn't have to mean 2 DHCPv6 servers. A single DHCP server can take PDs from 2 or more upstream ISPs. If the problem is that exit routers come with DHCPv6 servers, then adding the ability to disable all but one (automatically or manually) would be worth considering. Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Interop for OSPF-based homenet solution at IETF 85
On 30/10/12 17:16, Mark Townsley wrote: Group, When we created the homenet WG, we identified that open source code was a critical component in the consumer home router marketplace. As such, I thought I'd let the group know that there will be open source coders in our midst next week This may be an opportune moment to note that I too will be attending IETF, thanks to the tireless efforts and sponsorship of Dave Taht. I'm the main author and developer of dnsmasq, which is the open-source DNS forwarder and DHCP server component used in many home routers. Recent releases of dnsmasq have added DHCPv6 support, and future releases are slated to add DNSSEC validation. I'm keen to talk to anyone who has ideas and requests for further work on dnsmasq which will advance the homenet cause, and to anyone who can help provide resources to support that work. Cheers, Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
