Re: [homenet] wifi broadcast domain - Mikael Abrahamsson's comments

[Tore Anderson]

* Juliusz Chroboczek

>> If there is a more complex HNCP network, then we could probably simulate
>> the L2 scenario with VXLAN, configured by HNCP.
> 
> If memory serves, VXLAN requires support for multicast, which HNCP+Babel
> doesn't provide.  There's a set of IBM (?) extensions to VXLAN that avoid
> the use of multicast, I'm not a fan.

I think you'll find very few deployed production VXLAN networks using
multicast in the underlay for BUM flooding. It is far more common to have
some kind of control plane (could be distributed or centralised) that takes
care of that. EVPN (RFC 7432), for example.

To get rid of multicast in the underlay, you'd at minimum need to
distribute information in HNCP about which routers are interested in
receiving BUM traffic for a given VXLAN ID, so that all routers can install
forwarding table entries for BUM traffic pointing to all the remote tunnel
endpoints (VTEPs). BUM frames will then be copied and sent unicast to all
the remote VTEPs (this process is called «Head End Replication»).

More advanced control planes (like EVPN) will also distribute information
about where individual MAC addresses are located, so that there is no need
to flood and learn unknown unicast. Works like a charm.

Tore

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

Re: [homenet] How many people have installed the homenet code?

[Tore Anderson]

* Rich Brown

> (And I may take Tore up on his offer to push a feed of the newer
> packages to Github...)

I had some time to kill today, so here you go. Let me know if you find
it useful.

https://github.com/toreanderson/openwrt-feed

You're probably better off taking Markus's advice and staying with
stock CC though...use my feed at your own peril.

Tore

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

Re: [homenet] How many people have installed the homenet code?

[Tore Anderson]

* Rich Brown

> I'm new to this list, but have been using CeroWrt and OpenWrt for
> several years.

Welcome!

> Earlier in this thread there was a mention about hnetd being well
> integrated into the OpenWrt ecosystem. Before I try installing hnetd,
> I would like to know:
> 
> 1) What are the current recommendations for hnetd in OpenWrt? Barrier
> Breaker? Chaos Calmer? Trunk? Are there settings/bugs/etc. to be
> aware of?

Speaking only for myself, I'm using Chaos Calmer but backport newer
Homenet-related packages to ensure that I am up to date with the latest
bugs / bug fixes. I could publish my custom feed to Github in case
you're interested.

As for known bugs and issues, I'd check out the issues reported to
Steven's repositories:

https://github.com/sbyx/hnetd/issues
https://github.com/sbyx/odhcpd/issues
https://github.com/sbyx/ohybridproxy/issues

That said, think what's in CC works well enough for most uses, although
I've had issues with mdnsd causing out-of-memory crashes. That could be
because my old routers are underpowered, but then again I haven't seen
it since upgrading to the latest version available in the devel feed.

Tore

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

Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt

[Tore Anderson]

* Steven Barth 

> here is some attempt to formalize a simple WiFi roaming approach
> using host routes and a stateless proxy for DAD NDP messages.
> 
> It's a bit theoretical right now but may be useful as a start for a
> discussion. We could do a talk on it in Yokohama as well.

Hi Steven and thanks for this! It's a problem it's important to solve.

Some questions/thoughts after a very quick skim through:

>  A router MUST listen for all Neighbor Solicitations with a target
>  addresses from an assigned roaming prefix having the unspecified
>  address as the source address.  Similarly it MUST listen for all
>  Neighbor Advertisements with a target address from an assigned
>  roaming prefix and having the all-nodes multicast address as the
>  destination address.
>
>  A router MUST forward all such messages via global unicast to all
>  other routers having roaming interfaces sharing the roaming
>  prefixes the target address of the respective message belongs to.

(Similar language in section 3.2.)

Do I understand correctly that this will only happen for NS packets
destined for the globally scoped address? That is, no proxying of the
DAD messages for link-local addresses? Assuming clients don't re-start
DAD after having roamed from one BSS to another, isn't that a problem?

> The IPv6 address fe80::1 SHOULD be used as fixed link-local
> address exclusively by the router on roaming interfaces.

Isn't a more appropriate address to use for this the subnet-router
anycast address, i.e., fe80::? See RFC4291 section 2.6.1 - the intended
usage seems to be quite fitting for your use case:

   The Subnet-Router anycast address is intended to be used for
   applications where a node needs to communicate with any one of the
   set of routers.

Finally:

> Stateful DHCPv6 MUST NOT be used to avoid the need to synchronize
> lease information and relay DHCPv6 packets.

What about DHCPv6 Prefix Delegation? Not supported? I think there is a
use case for supporting PD to wireless clients if possible (think
virtual machines, 464xlat, etc.)

Tore

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

Re: [homenet] Host naming in Homenet

[Tore Anderson]

* Juliusz Chroboczek

> > BTW - this reminded me that I also noticed that after rebooting a
> > router, another ULA prefix (*not* the one configured in OpenWrt on
> > either router) also showed up and links were numbered using it, but it
> > vanished again after a while. No idea where it came from. To be
> > investigated! :-)
> 
> See Section 6.5 of hncp-08:
> 
>   An HNCP router SHOULD create a ULA prefix if there is no other IPv6
>   prefix with a preferred time greater than 0 in the network.
>   It MAY also do so, if there are other delegated IPv6 prefixes, but
>   none of which is locally generated (i.e., without any Prefix
>   Policy TLV) and has a preferred time greater than 0.  However, it
>   MUST NOT do so otherwise.  In case multiple locally generated ULA
>   prefixes are present, only the one published by the node with the
>   highest node identifier is kept among those with a preferred time
>   greater than 0 - if there is any.
> 
> If memory serves, by default the OpenWRT implementation will create a
> ULA even if there are GUA prefixes.  If you reboot a router, the
> election of the ULA might in principle cause transient ULAs to appear.

Right. What I'm experiencing is however the existence of *two* ULAs,
one transient, and one permanent. See the screenshot below, taken after
disconnecting the ISP-facing "WAN" interface:

http://fud.no/openwrt-homenet-dual-ula.png

The fd30:35c6:9ee8::/48 prefix configured under «IPv6 ULA-Prefix» near
the bottom was automatically generated when OpenWrt was installed, and
all active interfaces on that router (even the "WAN" one) are numbered
with /64s from it at all times.

My other Homenet router also has a auto-generated «IPv6 ULA-Prefix»
setting which it numbers all of its interfaces from at all times. That
means that during normal operation, hosts on a link between the two
routers will have addresses from three prefixes: The ISP-delegated GUA,
router 1's ULA, and router 2's ULA. R1 doesn't configure its local
interfaces with addresses from R2's ULA or vice versa.

fd98:d432:6004::/48 is the transient ULA here. When this is present,
both R1 and R2 configure their local interfaces with it (so hosts
connected to the R1-R2 link will at this point have acquired addresses
from four distinct /64s: one ISP-delegated GUA, two permanent ULAs, and
one transient ULA).

What I am starting to suspect is that OpenWrt's «IPv6 ULA-Prefix»
setting is orthogonal to the Homenet handling of the interfaces, and
that in order to get the full/correct «Homenet experience» I should
disable this setting on all my routers. It could perhaps be considered
a bug that the «IPv6 ULA-Prefix» is used to number interfaces set to
Homenet/HNCP mode in the first place? I'd appreciate it if you could
confirm whether or not this is the case.

Also, to answer you other question - yes, I do have a spare router
lying around, and I do intend to try setting up wireless transit link.
I'll let you know how it went, but it'll take a while before I get
around to it, as I have to wait for a +3.3V UART to be delivered before
I can get OpenWrt installed on it.

Tore

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

Re: [homenet] Host naming in Homenet

[Tore Anderson]

* Markus Stenberg 

> Instead, it sounds like potentially issue with IPv4 + dnsmasq (e.g.
> option that prevents RFC1918 replies from being forwarded), I hope
> you are not using legacy IP :)

I left everything at defaults, so my links were indeed numbered using
IPv4 (RFC1918, 10/8), as well as IPv6 ULA from a prefix automatically
set up by OpenWrt when the router was installed (pre-Homenet
conversion) and of course IPv6 GUA (from ISP/DHCPv6-PD). I'll try to
remove the option you mention and see if that's better, thanks for the
tip!

BTW - this reminded me that I also noticed that after rebooting a
router, another ULA prefix (*not* the one configured in OpenWrt on
either router) also showed up and links were numbered using it, but it
vanished again after a while. No idea where it came from. To be
investigated! :-)

> (We intentionally touch as few defaults as possible, and that
> protection is on by default IIRC)
> 
> Another caveat is that DHCP-derived names within dnsmasq are not
> currently distributed outside (local) dnsmasq but instead just
> provided locally, possibly with some weird domain that other routers
> do not know about. (dnsmasq extensibility leaves something to be
> desired.)

Understood.

Thanks!

Tore

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

Re: [homenet] Moving forward.

[Tore Anderson]

* Sander Steffann san...@steffann.nl

  Op 10 aug. 2015, om 10:23 heeft Erik Kline e...@google.com het
  volgende geschreven:
  
  Whilst not wanting to de-rail any effort to standardise Babel
  (since I firmly believe it should be standardised), I'd like to
  hear the WG's view on having part of our Homenet stack be on
  Experimental Track instead of PS.  E.g., would it affect vendors'
  willingness to implement Homenet, etc?
  
  +1
  
  Especially if that got us to a place where 2-3 years from now we
  could publish {D,H}NCPbis incorporating lessons learned and whatnot
  as a Proposed Standard, I think that would be a perfectly acceptable
  outcome.
 
 +1

Indeed.

Experimental Track would at least mean being on *a* track, which is
more than could be said about the status quo, IMHO. 

Tore

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

Re: [homenet] HNCP, RA and DHCPv4

[Tore Anderson]

* Juliusz Chroboczek

  After that you can also include the PIO with PL=VL=0 in the periodic
  RAs (that you'll presumably be transmitting anyway)
 
 How many PIOs will fit?  Is the 1280 octet minimal MTU the only
 limitation?

I don't think there's any practical limit, considering that you can
simply send multiple RAs if necessary. RFC 4861, section 6.2.3:

   If including all options causes the size of an advertisement to
   exceed the link MTU, multiple advertisements can be sent, each
   containing a subset of the options.

(I'm not saying that I think doing so for a ton of withdrawn prefixes
for several weeks or months would be a good idea or anything, but is
technically possible.)

Tore

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

Re: [homenet] HNCP, RA and DHCPv4

[Tore Anderson]

* Steven Barth

 If a new host is connecting to the network while you're advertising
 the max(old valid lft, 2h) valid lifetime, it will actually
 auto-configure itself with an address from the withdrawn prefix. If
 you set valid lifetime to 0, it won't.
 
 Sounds good, i don't mind. Just have to phrase so that it's sent more
 than once in any case. We could also say it needs to be sent in 3
 successive RAs independent of the time frame. What do you people
 think? 

Yes, I think retransmitting those RAs for a while is a good idea.
Multicast RAs might get lost, especially on WiFi, and to make matters
worse some devices will rate-limit them in order to conserve energy (cf.
I-D.ietf-v6ops-reducing-ra-energy-consumption). So I'd say firing of a
volley of a few (*at least* 3, IMHO) RAs with a short interval
immediately following the flash renumbering event sounds sensible.

After that you can also include the PIO with PL=VL=0 in the periodic
RAs (that you'll presumably be transmitting anyway) for several hours
(in order to hopefully get through to any RA rate-limiting devices that
might have missed the initial volley). I don't see any damage that
could be caused by doing so - devices that saw the initial volley as
well as newly-connected devices that never had an address in the prefix
to begin with will simply ignore that PIO. Maybe doing that for approx.
two hours would make the most sense here, as that's most likely the time
the addresses will actually start disappearing from the hosts that saw
the initial volley.

Tore

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

Re: [homenet] HNCP, RA and DHCPv4

[Tore Anderson]

* Steven Barth

 In an ungraceful case (flash renumbering) we stop announcing the prefix in
 HNCP and the individual routers who have assigned it, MUST deprecate it
 according to RFC 7084 (not just stop announcing it in RAs). This deprecation
 sets preferred lifetime to 0 and valid lifetime to max (old valid lft, 2h).

Hi Steven,

Why don't you set the valid lifetime to 0 as well?

If a new host is connecting to the network while you're advertising the
max(old valid lft, 2h) valid lifetime, it will actually auto-configure
itself with an address from the withdrawn prefix. If you set valid
lifetime to 0, it won't.

This comes to mind:

https://www.rfc-editor.org/errata_search.php?rfc=6204rec_status=1presentation=records

Tore

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

Re: [homenet] Moving forward.

[Tore Anderson]

* Hemant Singh (shemant) shem...@cisco.com

 (c) An average home has one wifi link.

I think you'll find that an average home has more than 1 wifi link.
Maybe somewhere between 1 and 2 is the correct number.

For example: The concrete between the two floors in my apartment makes
an AP located upstairs practically unusable from downstairs and vice
versa. So I have two bridging APs that share the same ESSID and are
connected to the same wired layer-2 segment. That works well enough.

Tore

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