Re: [homenet] [Int-area] [Captive-portals] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
>We need some diagrams that we can all agree upon, and we need to name the >different observers. > >Each thing defends against different kinds of observers, and not all >observers can see all things. Observer may be the wrong term, the more standard term is attack scenario. Some attacks are passively observing the network, but many attacks are more complex than that. For example, an application may phone home, an attacker may actively probe a network, an attacker may combine different pieces of information. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review security considerations of draft-homenet-babel-profile
>>> Yeah, the so-called "TTL hack". > >> Care to explain why it would not be useful? > >At the time I wrote down Babel, I decided that given that we have link-local >addresses that are securely scoped to a single link, the TTL hack is not >necessary. The TTL hack is used in ND. It strikes me as really bad for security to come up with a different mechanism to achieve the same result for no other reason than that you for some reason didn't like that trick. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review security considerations of draft-homenet-babel-profile
>Yeah, the so-called "TTL hack". Care to explain why it would not be useful? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review security considerations of draft-homenet-babel-profile
In your letter dated Wed, 26 Jul 2017 20:49:10 +0200 you wrote: >> Historically, a popular brand of router would forward packets with LL source >. > >"Historically"? Has this been fixed? I wanted to give them the benefit of the doubt. Sometimes they do fix a bug and I didn't want to spend any time figuring out if this one was fixed or not. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review security considerations of draft-homenet-babel-profile
>Nasty comments on list, please, compliments by private mail ;-) A trick used in some places, such as ND, is to require the receiver to check that the hop limit is equal to 255. This ensures that the packet has not been forwarded by any router (obviously the sender also has to send it with a hop limit of 255). Historically, a popular brand of router would forward packets with LL source. So that cannot be considered safe in general. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] draft-pfister-homenet-dot-00
Some remarks regarding draft-pfister-homenet-dot-00: (I'll ignore the specific value '.homenet') Section 2: "or only reachable from within the home "network (e.g., a web server hosted by the service provider and "providing a service that is specific to the home)." I think it is best to drop this. Maybe add that a homenet domain name may resolve to addresses outside the homenet without specifying why. "DNS queries for names ending with '.homenet.' MUST NOT be sent "outside of the logical boundaries of the home network. This basically impossible. Anybody can specify a well known public resolver (like Google's 2001:4860:4860::) in /etc/resolv.conf. And Section 3, point 3 prevents stub resolvers from treating homenet special. Section 3: "5. Authoritative DNS Servers SHOULD recognize such names as special- "use and SHOULD NOT, by default, attempt to look up NS records for "these names. How can an authoritative server consider itself authoritative for any zone by default and how whould it get a query in the first place? "6. DNS server operators SHOULD NOT attempt to configure DNS servers "to act as authoriative for any of these names. Again not sure why this would be problem. How to these servers queries for homenet? Or is this specific to DNS resolvers? "7. DNS Registries and Registrars MUST NOT assign any sub-domain from "'.homenet.'. Again this feels weird. How can registries and registrars operate on domains that are not delegated to them by ICANN? At the same time, the draft fails to specify what should go in the root zone (or any other zone from which '.homenet' would be delegated) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] write up of time without clocks
>You write TLS, but really, I think you mean PKIX (certificates). >AFAIK, TLS with raw public key or PSK doesn't care about time. > >While this might be a pedantic point, I think it's important to be clear >about where the problem is because it reveals that there are TLS uses which >do not have problems, but also that the time problem is not just about TLS >and DNSSEC. My reasoning was the following: Assume a device that has no idea about time when it boots. Assume that some security protocols (DNSSEC, TLS most of the time, etc) have as a requirement secure, somewhat accurate time. So we need a protocol that allows the device to fetch the current time in a way that doesn't allow an attacker to interfere. Now also let's assume todays internet. We can design fancy new time protocols, but if they take decades to deploy then it doesn't do much good. So a very simple protocol to obtain secure time is to have the device ask a preconfigured server. This protocol then needs to have two properties: - The time returned by the server has to be authenticated and integrity protected (and the device has to be able to verify this) - The timestamp has to be fresh (and the device has to verify this) So this can easily be implemented using standard protocols such as HTTPS: - The device needs to have a long lasting certificate for the server (lasting long enough that time irrelevant) - The device has to be configure to require forward secrecy, or any other TLS configuration that guarantees that replay is impossible. - The device issues a simple 'GET /' and gets the current time back in the response header. So if you want to bootstrap secure time today, this is an easy way to use existing protocols. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] write up of time without clocks
>Which in some implementations, means having a clock to know that your current >firmware is actually newer than the "proposed" new firmware (which is really >much older), or knowing that it's been too long since a firmware load. Where I entered the discussion is basically saying that only way to get secure time on today's internet that sort of scales is to start a TLS connection with a server you trust. One thing we could do is to design a secure time protocol, but I doubt that that is going to fly, and certainly not in the near future. Another thing would be to adapt security protocols to deal with less secure or less accurate time. But that requires actually going over DNSSEC and TSL and possibly other protocols and think about the effects of less secure or less accurate time. That can be done, but some working group would have too actually do the work. So that leaves me with the conclusion: if you need DNSSEC or TLS for security purposes, then the only way to be secure is to fetch the time using TLS from a server you trust. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] write up of time without clocks
>>> ddos attack like against Dyn > >I could be wrong, but I believe that Dyn was DDoSed by the Mirai botnet, >which propagates by exploiting devices configured with default credentials. >This has nothing to do with outdated firmwares. The problem is that you cannot realistically update those firmwares. If is trivial to compile a new firmware for those devices that doesn't request upnp to open ports to telnet or ssh. But is is impossible to deploy such an update. For consumer electronics, we cannot rely on consumers to actually download and install new firmware. So part of the solution to securing those devices has to be that (out of the box) they will update automatically. For the same reason, having lots of devices on the internet that have been abandoned by the vendor is also a huge security risk. So ideally those devices should shutdown automatically. Note that PCs, browsers, etc. are now somewhat secure because they update automatically. We need to do the same will all other devices connected to the internet. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] write up of time without clocks
> This started with a need for somewhat accurate system time for > certificate validation, right? I have to deal with stuff lacking > a RTC battery. I save system time every now and then in flash. > During startup, clock jumps forward to RTC when warm start occurs > (main power was not interrupted) or to saved system time when a > cold boot occurs. When clock is behind, it jumps forwards when NTP > syncs. My certificates do not expire during "powered off, on the > shelf". The problem is that security protocols like TLS and DNSSEC rely on secure, accurate time without specifying how to get that. At the moment we don't have any way to distributee secure accurate time of a large scale. Without accurate time you have too fool around to make it work. And without a serious security analysis, you will only find out what it means to rely on a best effort time service when the security of your system is broken (or a security researcher gives a nice presentation on a security conference). Note that just saving the time to flahs is very likely to break DNSSEC. Many zones have very short lifetimes (in the order of weeks). So if the device is off for a couple of weeks, the local time will be before the start time of the signature and DNSSEC validation will fail. My guess is that as letsencrypt is becoming more wide spread, having a clock off by a couple of months will also cause issues there. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] write up of time without clocks
>> So the device should have the vendor's long term TLS certicate. With possibl >y >> an option for the user to disable this kind of security if the device is >> not actually connected to the internet. > >No, during disaster recovery the last thing you need is for ordinary people >to be faced with strange security alerts that they've never seen before. >(It's rather like advising people to go into the BIOS to change an option >while the fire alarm is ringing.) > >Things need to just work during disaster recovery. Maybe I live in an unusual part of the world. But this seems very far fetched to me for two different reasons: - I rate the risk of ddos attack like against Dyn way higher than a large physical disaster. Though I have to admit that there are parts of the world where the risk of disaster is a lot larger than here. Of course, building code also very from country to country taking into account disasters that may take place. - The bigger issue is that I can easily imagine partial internet access, but that is mostly unrelated to physical disasters. I'm really curious how you think a disaster leaves the internet broken enough that CPEs can't phone home, but working well enough that people in the middle of can communicate with each other. That said, if you think that there is a strong need for CPEs to continue to work in a badly damaged internet, then it makes sense to make that an official requirement. If requires specifying what this badly damaged internet really looks like and how to test if devices can cope. Otherwise, CPE vendors may just silently implement what I suggest and we will only find out during a disaster where things don't work. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Babel-users] Detecting bridges
>> I.e., a router on wifi announces wifi and when a router that is on wired >> receives an announcement from a router on wifi it knows that there >> a bridge somewhere. > >Not a bad idea, but I'm a little hesitant to implement that, since it >would require defining a taxonomy of interface types at the protocol >level. (Currently the taxonomy exists in the implementation, but it >doesn't appear in the protocol -- the protocol only knows about metrics.) It is probably not such a good idea to literally say 'wifi', but if a set of metrics could be defined that describe that expected stability of a link then a router could annouce which it has configured or discovered. One thing to consider though, in my experience lossy links make for a very bad user experience. So if a disconnect happens as a result of user action, say moving a wifi device from one room to another, then losing the link is not a bad deal. If links just come and go then ultimately users will just complain that the internet is bad. If bad links are unavoidable, it is better to run a tunneling protocol on top of those links with forward error correction or other mechanism to make the link more reliable. (I.e, it might better if babel degrades gracefully, instead of trying to make bad links 'work') ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Babel-users] Detecting bridges
In your letter dated Wed, 16 Dec 2015 18:01:43 +0100 you wrote: > 1. use the wireless type by default (as with -w), people who have >lossless wired links will need to configure them manually; this is bad >for Homenet, which is expected to use wired links extensively, but >perhaps it doesn't matter, Homenet can accept 15 seconds instead of 6; Is there room in the protocol for a router to announce what link type it is on? I.e., a router on wifi announces wifi and when a router that is on wired receives an announcement from a router on wifi it knows that there a bridge somewhere. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
In your letter dated Wed, 26 Aug 2015 15:07:50 +0200 you wrote: On Wed, Aug 26, 2015 at 2:31 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: What I'm saying is that neither DHCPv4 nor IPv6 RA are designed to deal with prefixes that last less than a few hours. See for example RFC 4862 Section 5.5.3 paragraph e2. (That's just an example, there are other reasons why yo-yo RAs are a bad idea.) Short-term reachability indications are sent to hosts in a reactive manner, using ICMP unreachables. If any applications are unable to do the right thing with ICMP unreachables, we should fix the applications. I am not aware of any application doing anything more than try to open the connection again. How do you propose the application to react? Most applications leave the source-IP selection to the operation system... does any OS currently change the preference order of IPv6 source prefixes when it gets ICMP unreachable messages? I never bothered to automate, but I regularly switch prefixes by changing the preference times in RAs. That works very well. Linking general ICMP unreachable messages to a source prefix sounds very hard to me. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Let's make in-home ULA presence a MUST !?
In your letter dated Wed, 15 Oct 2014 16:58:43 +0200 you wrote: Please understand that there are way more non-geeks out there that have no interest in computers except use them than there are geeks who care about IP addressing. *Our* job is to make it work for *them*, without forcing our world view on them (they need to be able to put a static IP address in DNS! - no, my mom doesn't need to do that) Our current 'world view' is that companies get stable addresses. Consumers get crap. We invent complicated stuff like dynamically turning ULA on and off that nobody else uses. We force renumbering in the name of privacy, etc. We start by giving consumers a swamp and then try to build something on top of it. We make choices, like the DNS server has to be in the router, because only the router knows about the current prefix, etc. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Let's make in-home ULA presence a MUST !?
In your letter dated Tue, 14 Oct 2014 16:59:30 +0200 you wrote: Because this is the only way that application developers will learn to handle it. I'm happy my ISP doesn't do that. I would probably just use a tunnel instead. One of the advantages of IPv6 is that it is way easier to run publicly accessible services at home. You still need to put an address in DNS, but that's a one time action. (It would have been nice if there was a way to signal that this prefix is sort of stable and that home routers would remember that. But I'm not holding my breath) Hmm, if changing prefixes is such a great idea, then maybe RIRs should do the same :-) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
In your letter dated Fri, 18 Apr 2014 09:57:21 -0430 you wrote: You are absolutely right, thanks. But anyway the scenario I mentioned above can also exists (and for good or bad eventually will happen).. I just wanted to express my position about the option NO-IPv4 in DHCPv4 I'd say that if you want to play games and turn off IPv4 for some hosts and not for others then you are better off putting the option in DHCPv4. Putting the option in RA makes it all or nothing. You either tell all IPv6 hosts to turn off IPv4 or none. Putting the option in DHCPv6 requires careful coordination between the DHCPv6 and DHCPv4 configs. The DHCPv6 server would have to send the option in the IPv6 config and the DHCPv4 server has to refrain from sending an offer. This can be tricky if the DHCPv4 and DHCPv6 device ids are different. In contrast, putting the option in DHCPv4 only requires setting a flag in the DHCPv4 config that particular host should not get IPv4. If we require the DHCPv4 client to include the option in the DISCOVER then it is also easy to tell old and new hosts apart. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
In your letter dated Thu, 17 Apr 2014 22:16:19 -0430 you wrote: I like the idea of having the No-IPv4 option for DHCPv6. I don't like the idea of having this option in a v4 world; mainly because in mix networks where you might have some folks which only speak IPv4, imagine a case where this option is sent by a DHCPv4 to a client who do not understand v6. Of course, probably the client won't understand the option and won't turn off IPv4. There is also the chance that this is a modern OS but for some reason IPv6 was disable in the host, yes, it will understand the option No-VP6 (sent by a dhcp4). As far as I understand, this draft addresses the situation where the network doesn't offer IPv4 in the first place. So any IPv4-only host would have no internet connectivity anyhow, whether it processes the option or not. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
In your letter dated Wed, 16 Apr 2014 09:07:46 -0400 you wrote: Philip Homburg pch-homene...@u-1.phicoh.com wrote: Does that include all edge cases and the user interface? I.e. DHCPv4 has configured an address and by mistake a RA orders IPv4 to be shutdown. Do you just shutdown IPv4? Does your code parse the output of ifconfig to figure out if the interface was configured? No, and no. The order is not to shutdown v4. The suggestion is to stop DHCPv4, if it hasn't succeeded, and assume that there isn't any IPv4 for any downstream devices. (This was in the context of FreeBSD.) One option: the DHCPv4 client has an option to shutdown unless it already obtained a lease. Probably requires allocating a signal, changes to the DHCPv4 client, etc. Otherwise, what happens if you kill a DHCPv4 client when it has a lease? - A hard kill (-9) and the address remains installed even when the lease expires. Not good. - (Unlikely) A hard kill and the kernel knows about the lifetime of the lease and deletes the address when it expires. This one would be really great to debug. Send one 'ipv4begone' packet and hour later the admin goes crazy. - A soft kill (say TERM) and DHCPv4 removes the address before shutting down. Nice immediate DoS on IPv4. Alternative, ifconfig $interface | grep 'inet '... Ugly. And unless all of this is spelled out in the RFC in extreme detail, I can already see the presentations in a couple of years: we sent one 'ipv4begone' packet and this is the kind of fireworks you get in the various operating systems. Somebody might just go ahead and implement 'grep option no-ipv4 /var/db/dhclient6.leases.eth0 pkill dhclient' ... ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
In your letter dated Tue, 15 Apr 2014 09:46:38 -0400 you wrote: Le 2014-04-15 07:28, Toke H=F8iland-J=F8rgensen a =E9crit : Simon Perreault simon.perrea...@viagenie.ca writes: = Correct. But if DHCP or RAs are not filtered at layer 2, a rogue user can already do this today without this extension. = Right, to a certain extent that is true, of course; but not in the same drive-by fashion where a single packet can put everyone offline (if the option is not in the regular announcements). Sure it can. Just send them to a non-existing default gateway. Unless I misunderstood your point. Right now, on any network that doesn't do IPv6, sending RAs has marginal effect. Certainly traffic within the site would be unaffected if there are no IPv6 addresses in DNS. With an RA that kills IPv4, that changes dramatically. Sounds like something no sane OS vendor would enable by default. From an OS perspective, I'd rather have this option in DHCPv4. That part of the code knows about IPv4. Getting the IPv6 stack to tell the IPv4 stack to shutdown is complicated and probably won't be implemented until enough people bitch about it (and how stupid the IETF was) for quite some time. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
In your letter dated Tue, 15 Apr 2014 11:24:48 -0400 you wrote: Le 2014-04-15 09:56, Philip Homburg a écrit : Right, to a certain extent that is true, of course; but not in the same drive-by fashion where a single packet can put everyone offline (if the option is not in the regular announcements). Sure it can. Just send them to a non-existing default gateway. Unless I misunderstood your point. Right now, on any network that doesn't do IPv6, sending RAs has marginal effect. Certainly traffic within the site would be unaffected if there are no IPv6 addresses in DNS. With an RA that kills IPv4, that changes dramatically. Sounds like something no sane OS vendor would enable by default. You can do the same today with a rogue DHCPv4 server. No, you can't if the switches filter DHCP. DHCP also has a completely different failure mode than RAs. To subvert DHCP you have to wait for clients to send out DHCP discovers. For RA, you just broadcast a couple of RAs. A rogue DHCP server is annoying, but usually affects a few clients. A rogue RA affects then entire subnet. What you are doing is making IPv6 filtering mandatory on any network that wants to do just IPv4. From an OS perspective, I'd rather have this option in DHCPv4. That part of the code knows about IPv4. Getting the IPv6 stack to tell the IPv4 stack to shutdown is complicated Please tell me how this is complicated: $ grep option no-ipv4 /var/db/dhclient6.leases.eth0 pkill dhclient For the systems I know, it would be trivial to implement. I could go and submit a patch to NetworkManager today. Yes, and by the time this is fully configurable, you are talking about many hundreds lines of code. You are not going to just kill your DHCPv4 client each time you receive a rogue RA. At least, not if you want people to use your OS. and probably won't be implemented until enough people bitch about it (and how stupid the IETF was) for quite some time. This is an argument that always comes back with any proposal. I totally disagree with it. Anyone could code this up and submit a patch to Android. Then when the next release happens, bam, lots of support overnight. Yes, and all security consultants will have a field day either selling patches to disable this or selling switches that can filter RAs. With your proposed code (actually killing dhclient) any mistake means that you have to reboot all systems in the affected LAN. Which means that any serious vendor will spend a lot of code making sure that the DHCP is only suspended for a couple of RA intervals, which leads to a way more complex interaction. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
In your letter dated Tue, 15 Apr 2014 12:05:59 -0400 you wrote: http://resources.infosecinstitute.com/slaac-attack/ When you have unfiltered L2 access, there are LOTS of evil things you can do. The world is not black and white. Rogue RAs are easy for hit and run attacks. Maybe I should already create 'ipv4begone'. Would be a nice way to reserve the wireless for yourself in busy wifi networks. In contract MITM attacks are much harder to pull off. Any don't really gain much compared to just sniffing the wifi. No, you can just re-send the No-IPv4 option with value 0. We added it specifically to re-enable IPv4 when it has been previously disabled by mistake. So now, any RA daemon also has to know to start dhclient. So it is more than just your oneliner. And this is one advantage of using IPv6 for signalling the absence of IPv4 service. If you use IPv4 instead, and you make a mistake, there's no going back. Not if you just suspend DHCP operation for a while... Which means that any serious vendor will spend a lot of code making sure that the DHCP is only suspended for a couple of RA intervals, which leads to a way more complex interaction. As discussed with Ted Lemon, the next revision will specify that the No-IPv4 effect only lasts for the lifetime of DHCPv6 or RA. Similar to what you describe here. There is of course an easy way out. Let this run its course and then write an informational RFC that allocates the required option for DHCPv4. More choices are always better... Let the OS vendors decide. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
In your letter dated Tue, 15 Apr 2014 11:24:31 -0500 you wrote: I think you are talking apples and oranges. Simon, you are assuming a functio nal configuration environment; in such an environment, the change would be fair ly trivial. Philip, I think you are assuming the current status quo on linux, which is badly broken and requires massive amounts of work to make small chang es. In that context, it probably is hundreds of lines of code. But that really needs to get fixed regardless of the outcome of this discussion . I'm also thinking about the code base for an embedded system I maintain. And I can really do without more complex interactions between IPv6 and IPv4. Adding an IPv4 suspend option to DHCPv4, that's easy. Doing the same thing from IPv6 is a nightmare. In any system that does DHCPv4, suspending IPv4 for a while is a purely local interaction with the DHCPc4 client. If you implement it for the most common DHCPv4 clients, you can probably get it implemented in little time. On the other hand, if you need have RAs signal suspend and resume of IPv4 you are looking at rewriting the management code of lots of different Linux distibutions (including various embedded ones) and many operating systems. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
In your letter dated Tue, 15 Apr 2014 12:09:48 -0500 you wrote: On Apr 15, 2014, at 11:47 AM, Philip Homburg pch-homene...@u-1.phicoh.com wro te: On the other hand, if you need have RAs signal suspend and resume of IPv4 you are looking at rewriting the management code of lots of different Linux distibutions (including various embedded ones) and many operating systems. Yes. That will be a really good outcome. You really think people are going to rewrite Linux network config for some weird edge case? I'm sorry, but I have no sympathy for your protestations about DHCPv4 clients i n embedded applications. If it's an RPi, you can run a full-featured DHCPv4/D HCPv6 implementation that works, so there's no excuse for running one that does n't. If it's a tiny sensor, you want to use 6lowpan anyway, so you're not run ning DHCPv4 _or_ DHCPv6. And you also always have the option of just ignoring the option if you are implementing something that really is an edge case. Then you don't. I'm only saying that from my perspective, changing DHCPv4 is the best technical solution. Now of course, the IETF can pick the option that requires serious changes in many operating systems, creates very interesting attacks, etc. Then that's just too bad. Note, this is an edge case. Operating systems hardly benefit from this option, but they will get the full load of any security issues. So my guess is that staying on the RA/DHCPv6 route will just seriously delay the implementation of this option. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
