Re: [homenet] HNCP

2014-02-14 Thread Ray Hunter



Mark Townsley wrote:


All,

In case anyone missed it, Markus and Pierre posted drafts and a 
pointer to an implementation describing the Home Net Control Protocol.




Running code is very welcome.


I'd like to provide some additional background, hat off.

The work Markus, Stephen and Pierre have been doing is funded by a 
Cisco Technology Fund grant. The purpose of this grant has been to 
deliver technology backed by open source code that will be adopted by 
a community willing to maintain it, with the ultimate goal of that 
technology making its way into commercial product (for this to matter, 
it needs to make it into far more than Cisco product). During its 
first phase of operation, the main focus was on work originally 
started by Jari Arkko, Acee Lindem, and Benjamin Paterson in OSPF by 
fleshing this out in code and spec. Much was learned, and you may have 
seen some of the results at various bits-n-bytes and in draft updates 
(or the Markus' github if you were watching). The second phase, which 
began after the Berlin IETF, has been to take what was learned in the 
first phase and focus on:


- upstreaming the technology into an open source project (in this 
case, OpenWRT)

- modularity and adaptability to other routing protocols (e.g., ISIS)
- best-effort capabilities in simple topologies in case one common 
routing protocol support was not available
- integration with draft-behringer-homenet-trust-bootstrap 
and draft-kline-default-perimeter


The result after several months of heads-down effort is contained in 
the drafts below. The document from pfister is an evolution of the 
IPv6 prefix assignment work started by Jari, but in its own document 
such that it can be referenced by to OSPF, ISIS, HNCP, etc. The two 
from stenberg describe HNCP, as well as a general way to support 
Stuart's work in draft-cheshire-mdnsext-hybrid in a zeroconf mannter 
when the list of routers in a site is known (as HNCP does, or any 
link-state routing protocol should).


Personally, I was very skeptical when the team let me know that the 
result of their analysis led them to the need to create HNCP. If 
nothing else, between the OSPF work done in Phase one, and the HNCP 
work in Phase two, these are two concrete examples in draft and code 
form for the WG to examine to help decide the first question at the 
top of Ole's flowchart posted here earlier.


For those with no time to read the drafts, here's my one paragraph 
synopsis of what HNCP does:


HNCP uses the Trickle (RFC6206) algorithm to trigger when basic 
configuration state for the homenet is out of sync on any router. 
Essentially, a hash (or signature if security is present) over an 
ordered list of the known homenet nodes and attributes necessary to 
keep the homenet alive is handed over to Trickle. Trickle worries only 
about that hash value, and whether all nodes agree that the value is 
the same. When they don't agree, HNCP sends update messages between 
nodes until Trickle is happy again. The HNCP document also defines 
some specifics used in the OpenWRT implementation for border detection 
(based on draft-kline-homenet-default-perimeter), some hooks for 
integration with Behringer's trust bootstrapping (not 100% finished 
though), IPv4 and IPv6 prefix distribution, and an auto-negotiation 
mechanism depending on what type of routing protocol support is 
available. In the event no common routing protocol is available, HNCP 
defines a fallback mode that at least gets packets out the right 
interface and avoids loops, even if the path is not ideal, has no 
metrics, etc.


This is all pretty close to what the team set out to achieve with the 
4 bullets above as constraints and guidelines. Of this I can't help to 
be impressed. It came with a new protocol though, which shouldn't be 
taken lightly, but indeed might be necessary. I look forward to what 
the WG ultimately decides here.


Finally, if you want to follow some of the work being done by Markus, 
Stephen, Pierre, et. al. without necessarily logging into a github to 
do it, you can poke around here: http://www.homewrt.org (it may be a 
tad behind the latest-greatest though).


Hat back on now… Tim, Ray and I are working with the ADs to get the 
homenet-arch doc through the system. According to Tim, all DISCUSS 
points have been worked out on email with ADs weeks if not months ago, 
and the results are in -12 which has been posted. We're back to 
prodding ADs for time and mental cache reloading of their issues for 
them to clear. Once that is finished, the WG will finally be at a 
point that it can officially work on solutions.


Now, as Markus asked, Discuss! :-)

- Mark


Markus Stenberg markus.stenb...@iki.fi 
mailto:markus.stenb...@iki.fi (and Pierre Pfister) wrote:



Drafts:
http://tools.ietf.org/html/draft-stenberg-homenet-hncp-00


I have read this draft. Quotes below marked  are from the draft


 Is there a case for non-link-local unicast?
Not IMHO. That could be extremely 

[homenet] New arch text: draft-ietf-homenet-arch-12.txt

2014-02-14 Thread Tim Chown
Hi,

For info, this draft is intended to address any remaining IESG comments.  
Emails have been sent to the ADs in question with the chairs copied.  We hope 
that any remaining DISCUSSes can be cleared before London.

Tim

On 14 Feb 2014, at 18:17, internet-dra...@ietf.org wrote:

 
 A New Internet-Draft is available from the on-line Internet-Drafts 
 directories.
 This draft is a work item of the Home Networking Working Group of the IETF.
 
Title   : IPv6 Home Networking Architecture Principles
Authors : Tim Chown
  Jari Arkko
  Anders Brandt
  Ole Troan
  Jason Weil
   Filename: draft-ietf-homenet-arch-12.txt
   Pages   : 52
   Date: 2014-02-14
 
 Abstract:
   This text describes evolving networking technology within residential
   home networks with increasing numbers of devices and a trend towards
   increased internal routing.  The goal of this document is to define a
   general architecture for IPv6-based home networking, describing the
   associated principles, considerations and requirements.  The text
   briefly highlights specific implications of the introduction of IPv6
   for home networking, discusses the elements of the architecture, and
   suggests how standard IPv6 mechanisms and addressing can be employed
   in home networking.  The architecture describes the need for specific
   protocol extensions for certain additional functionality.  It is
   assumed that the IPv6 home network is not actively managed, and runs
   as an IPv6-only or dual-stack network.  There are no recommendations
   in this text for the IPv4 part of the network.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-homenet-arch/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-homenet-arch-12
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-12

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] HNCP

2014-02-14 Thread Steven Barth

On 14.02.2014 17:45, Ray Hunter wrote:


The biggest obvious question to me is why is it desirable to negotiate 
a common Homenet routing protocol on the fly?


Upside is that it avoids a heated debate for now. But what else does 
it deliver?
I think your arguments about the downsides are valid and we have thought 
about them as well. However the current approach seems to be practical 
given the current situation that there is no common consensus about an 
IGP or about there even being an IGP that fits all use cases. Some 
people even argue that in some or many common cases an IGP might be 
overkill.


On top of that I even think if there would be a consensus in the near 
future then we still need autoconfiguration and source+dest routing 
standardized and adopted for that given IGP which will probably take 
quite some time as well.


So yes, there are limitations and hopefully this is not the final stance 
on this topic and at some point there is some kind of industry-consensus 
on an IGP. But honestly I don't see this happening any time soon.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


[homenet] RFC: dhcpv4 to slaac DNS naming scheme

2014-02-14 Thread Dave Taht
I had intended to submit this to the homenet wg, but appear to have goofed
in some way in getting it to the right place.

presently at:

http://datatracker.ietf.org/doc/draft-taht-kelley-hunt-dhcpv4-to-slaac-naming/

Abstract

   This memo presents a technique for using the hostname acquired from a
   DHCPv4 client request to publish  records on that domain name for
   public IPv6 addresses acquired by the same dual-stack host using
   SLAAC.

   On dual-stack networks, there is a need to automatically publish
   entries in the DNS for the public IPv6 addresses of an IPv6 host when
   it does not use DHCPv6.  IPv6 hosts can acquire IPv6 addresses using
   SLAAC, but there is no mechanism allowing them to register a name in
   the DNS database other than a DNS update, which would create a very
   difficult key management problem.  By combining the DHCPv4 hostname
   or client FQDN option with information acquired using ICMPv6, a
   lightweight DHCPv4 server on a home gateway or SOHO gateway can
   automatically publish  records for such hosts.



-- 
Dave Täht

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet