e bridge is still needed to properly support multi-device
multi-vendor system configuration, especially in cases where
trickle and babel don't meet their expectations. Naming
conventions able to span bridges would be able to adapt to
any number of strategies that might be used over Hom
On 1/19/16 5:05 PM, Suzanne Woolf wrote:
> Hi,
>
> On Jan 18, 2016, at 7:14 PM, Douglas Otis
> wrote:
>
>> RECOMMENDATION 1: The TLDs .corp, .home, and .mail be
>> referred to the Internet Engineering Task Force (IETF)
>> for potential RFC 1918-like protec
ds to be
clarified before meaningful headway can be made. Can anyone
offer meaningful guidance on this point?
Regards,
Douglas Otis
On 1/5/16 1:12 AM, Ray Bellis wrote:
> Dear all,
>
> You each indicated willingness to work on a document for the Homenet WG
> describing all aspects of
soon require a license and
expensive custom hardware.
After all, ham operators are granted a fairly large latitude
in the equipment they manage, most of it fairly programmable
in many critical aspects. A 4 watt handheld transmitter
costs less than $30 and comes wit
y
used by draft-ietf-dnssd-push-00 (DNS Push Notifications)
leveraging RFC2136 (DNS UPDATE) can be tailored to also
offer Service Browsing over TCP rather than with UDP queries
against "<_services._dns-sd._udp." to ensure a
scheme that plays well with rBridge and WiFi configurat
-dns-sd-threats-00
describes considerations not covered in RFC6762, RFC6763 or
RFC7368 when aggregate sizes of RRsets are overlooked,
especially in such environments.
This section, as well as the Security Considerations
section, does not ensure local resources are not externally
exposed.
Reg
seconds, whichever comes first. While some printers might be able
to handle direct Internet access, most can't. Many of these devices announce
their routable address via mDNS, hence the need for a network overlay. By
using a network overlay, Trust on First Use (TOFU) is less essential al
from being
deceived; it simply changes what is being unreliably shared. These methods
must be bog standard to ensure plumbing works as expected. One such method
might attempt to establish an overlay network using the private address space
defined for IPv6 and IPv4.
Regards,
Douglas Otis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
schemes can be
satisfied when ULAs have a common prefix. There are also many home routers
already able to combine GUA and ULAs. Add L2TP and it seems we are done.
Regards,
Douglas Otis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
ocal by mDNS while also permitting continued operation when ISP
up-links are disrupted.
For some references see:
https://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink
Regards,
Douglas Otis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
ternet.
Unfortunately, many in the homenet wg consider this to be a problem to be
resolved by the device rather than the homenet protocol.
Regards,
Douglas Otis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
ia stick access, etc. These devices were never intended to directly
interface with the Internet. These devices MUST NOT be assigned routable IPv4
or IPv6 addresses. Using mDNS proxy into DNS would be setting the stage for
major security disasters.
Regards,
Douglas Otis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
l/draft-otis-dnssd-mdns-xlink-03
As an experiment, a test was made using a new popular brand of an IPv6 enabled
printer. Discovery by name resolution and not by address probing for the
printer allowed Internet access without any logs created. This is a problem
not easily resolved using routable IP addresses.
Regards,
Douglas Otis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On Apr 6, 2014, at 9:32 PM, Dave Taht wrote:
> On Fri, Apr 4, 2014 at 8:08 AM, Douglas Otis wrote:
>>
>> On Apr 4, 2014, at 6:10 AM, Don Sturek wrote:
>>
>> Hi Douglas,
>>
>> As one who follows the WG and having a keen interest in homenet solutions,
&
s when it impairs network
boundary detection and potentially lists devices having default names
indirectly accessible by remote actors.
Please consider security implications for deployers as part of this thought
process. Even if only published as a BCP, it would be most helpful.
Regards,
n if it is just in the form of a BCP
that would be useful for deployment.
Regards,
Douglas Otis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
challenge the effectiveness of existing firewall
strategies. In an ideal world, all devices should be secure when exposed to
the Internet. Our world is not ideal.
Please consider the security aspects, and how we might be able to aid
deployment (even in the
17 matches
Mail list logo
