Subject: [homenet] The minimal Babel profile for Homenet

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 28 Oct 2015 13:13:55 +0100

Dear all,

As Ray mentioned in his mail, there's a need to define the minimum Babel
profile for Homenet.  Pro memoria, Babel is defined as follows:

  - the body of RFC 6126 defines the basic protocol, and leaves link
    quality sensing and route selection to the implementation.

  - Appendix A of RFC 6126 describes a simple algorithm for link sensing
    that is known to work reasonably well in many topologies.

  - Section 3.6 of RFC 6126 suggests using shortest metric with hysteresis
    for route selection; the actual algorithm is defined in Section III.E
    of http://arxiv.org/pdf/1403.3488v1.pdf .

  - the extension mechanism is described in RFC 7557.

  - there are a number of extensions that use RFC 7557 and are carefully
    designed to interoperate with pure RFC 6126 and with each other; of
    particular interest to Homenet are RFC 7298 (HMAC auth) and
    draft-boutier-babel-source-specific.

I suggest that the minimum Homenet profile should be defined as follows:

  (1) MUST RFC 6126, IPv6 subset;

  (2) SHOULD RFC 6126, IPv4 subset;

  (3) strong SHOULD a metric suitable for hybrid (wired + wireless) networks,
      SHOULD Appendix A of RFC 6126 until something else has been empirically
      shown to be better;

  (4) SHOULD apply hysteresis to route selection, but this is not critical
      in typical Homenet topologies (which are expected to be uncongested);

  (5) MUST draft-boutier-babel-source-specific;

  (6) MUST the MTI subset of RFC 7298 (HMAC authentication).

Other extensions are either not believed to be useful in typical home
networks (delay routing) or too experimental to warrant wide-scale
deployment (radio frequency-aware routing).

The status of the currently available implementations of Babel is as follows:

  - babeld 1.6.3: everything except 6.

  - Quagga branch (deprecated): everything.

  - pybabel: just 1.

  - sbabeld: subset of 1 and 2.

  - Bird version (work in progress): just 1 and 3.

If there is consensus on the profile described above, then we need to
write it up in an experimental draft and implement the MTI subset of
RFC 7298 in babeld.  Another cool hack would be to expand sbabeld to
implement exactly the Homenet profile and nothing else (it's almost
there), and to make it into a library that can be integrated in shncpd.

Is there consensus on the above?  Who volunteers to co-author the draft
with me?  (Markus?  Steven?)

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 28 Oct 2015 12:32:47 +0000

>   (2) SHOULD RFC 6126, IPv4 subset;

Why not MUST? Given the massive embedded base (and continued deployment of new) IPv4-only devices, I think the homenet architecture will be less than successful if IPv4 isn't mandatory to implement. It's ok for vendors to ship with IPv4 disabled by default, if that's what the vendor wants to do; but it has to be there.

Much as I would like to see the CE industry prodded to ship all products with IPv6 implemented and enabled, I don't think the prodding should be done by causing unnecessary pain for average consumers.
Barbara

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 28 Oct 2015 14:07:32 +0100

> Why not MUST? [...] I don't think the prodding should be done by causing
> unnecessary pain for average consumers.

Fully agreed, but I'm not sure what is the WG's thinking about IPv4.  RFC
7368 (Homenet arch) is conveniently vague about IPv4.  My reading is that
the authors of RFC 7368 expected that router vendors will use multiple NAT
for IPv4, and that they will ignore whatever we mandate.

OTOH, the HNCP draft does (mostly) the right thing wrt. IPv4, so I guess
we could ignore RFC 7368's lack of assertiveness here and say that RFC 6126
style IPv4 is MUST, except if IPv4 is not supported at all.  (I'm not
overly keen on the "MUST implement, SHOULD deploy" style of compromise.)

> It's ok for vendors to ship with IPv4 disabled by default

That's policy, in my opinion it's HNCP's job, not Babel's.  Babel should
run with IPv4 unconditionally enabled, if HNCP chooses to publish an IPv4
prefix, who is Babel to disagree?

I guess we're in full agreement here, just looking for the right wording.

-- Juliusz

---

From: Tim Chown <[email-masked]>
Date: Wed, 28 Oct 2015 15:19:00 +0000

> for IPv4, and that they will ignore whatever we mandate.

Well, it was simply written as per directed by the WG chairs to not explicitly
consider IPv4. The focus was on IPv6 home networking.

As it says in the intro:

"The architectural constructs in this document are focused on the
   problems to be solved when introducing IPv6, with an eye towards a
   better result than what we have today with IPv4, as well as aiming
   for a more consistent solution that addresses as many of the
   identified requirements as possible.  This document aims to provide
   the basis and guiding principles for how standard IPv6 mechanisms and
   addressing [RFC2460] [RFC4291] can be employed in home networking,
   while coexisting with existing IPv4 mechanisms.  In emerging dual-
   stack home networks, it is vital that introducing IPv6 does not
   adversely affect IPv4 operation.  We assume that the IPv4 network
   architecture in home networks is what it is and cannot be modified by
   new recommendations.  This document does not discuss how IPv4 home
   networks provision or deliver support for multiple subnets.  It
   should not be assumed that any future new functionality created with
   IPv6 in mind will be backward compatible to include IPv4 support.
   Further, future deployments, or specific subnets within an otherwise
   dual-stack home network, may be IPv6-only, in which case
   considerations for IPv4 impact would not apply.”

Or in other words, IPv4 is as it is. In practice, many home networks will be 
dual-stack for some time, so deployments need to consider IPv4.

The hipnet work, for example, which was strongly compliant with RFC 7368, 
included IPv4 delegations within the home net, so avoided multiple NATs.

> overly keen on the "MUST implement, SHOULD deploy" style of compromise.)

My understanding is that RFC7368 basically leaves you free to do as you will 
with IPv4.

> I guess we're in full agreement here, just looking for the right wording.

RFC 7368 does not mandate disabling IPv4, nor does it require IPv4 to be enabled :)

Tim

> 
> -- Juliusz
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Michael Richardson <[email-masked]>
Date: Wed, 28 Oct 2015 11:43:19 -0400

> Why not MUST? Given the massive embedded base (and continued deployment
    > of new) IPv4-only devices, I think the homenet architecture will be
    > less than successful if IPv4 isn't mandatory to implement. It's ok for
    > vendors to ship with IPv4 disabled by default, if that's what the
    > vendor wants to do; but it has to be there.

SHOULD is actually pretty strong.  It doesn't mean, "implement if you like"
(that's MAY).  It means, implement it, unless you have a serious reason why
you can't.

For instance, an IPv6 only IoT gateway probably has no interest in IPv4 if it
can get IPv6.  MUST would make that gateway non-compliant.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 28 Oct 2015 18:08:05 +0000

> can get IPv6.  MUST would make that gateway non-compliant.

Maybe conditionally mandatory? If the router can be used for routing IPv4, then it MUST implement the IPv4 routing protocol capabilities?
I prefer not leaving it up to implementers to decide what is a "serious reason" and what isn't, for something like this. To some, a "serious reason" is "it would be additional work." I would prefer to identify a condition for when it needs to be a MUST.
Barbara.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Oct 2015 16:25:30 -0400

STARK, BARBARA H <[email-masked]> wrote:
    >> SHOULD is actually pretty strong.  It doesn't mean, "implement if you
    >> like" (that's MAY).  It means, implement it, unless you have a serious
    >> reason why you can't.
    >> 
    >> For instance, an IPv6 only IoT gateway probably has no interest in
    >> IPv4 if it can get IPv6.  MUST would make that gateway non-compliant.

    > Maybe conditionally mandatory? If the router can be used for routing

That's what SHOULD is *for*
If you are concerned it won't get implemented, then any weasel room you leave
will be exploited.  At that point, the market gets to decide.

-- 
Michael Richardson
-on the road-

---

From: Ca By <[email-masked]>
Date: Sat, 31 Oct 2015 09:16:19 -0700

On Friday, October 30, 2015, Michael Richardson <[email-masked]>
wrote:

>
> STARK, BARBARA H <[email-masked] <javascript:;>> wrote:
Agreed on SHOULD

MUST unduly enshrines IPv4 and ... NAT