Subject: Re: [homenet] OT: unnumbered interfaces [was: 2nd Working Group Last Call...]

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 4 Jul 2013 22:02:21 +0900

On Sat, Jun 29, 2013 at 5:13 AM, Juliusz Chroboczek <
[email-masked]> wrote:

> > We'll expect each host to announce N routing entries, one per
>  > address, and document things as such.
> [...]
> > I assume the implementation does this today, then?
>
> The standalone babeld implementation does this by default.  The
> implementation included in Quagga has defaults consistent with the
> other routing protocols included in Quagga, and needs some
> reconfiguration to behave as you desire.
>
> Please have a look at
>
>   http://babelweb.wifi.pps.univ-paris-diderot.fr:8080/

Snazzy!

A couple of things aren't clear to me, though:

1. How does this support the IPv6 subnet model with link-local multicast
and link-local addresses and so on? The IPv6 over Ethernet RFC sort of
relies on that to work, and I'm wondering if it makes assumptions that
don't hold in a situation where every host has to announce /128s.
2. Also, what about DAD? If all the hosts participate in the routing
protocol, you can implement DAD over that, but what about current hosts?

Cheers,
Lorenzo

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 04 Jul 2013 19:35:20 +0200

> Snazzy!

Thanks.

> 1. How does this support the IPv6 subnet model with link-local
> multicast and link-local addresses and so on?

Nothing changes.  Link-local addresses are still assigned to each
interface, as usual.

In a pure mesh network, the behaviour of link-local multicast changes
somewhat, so things like mDNS don't work well.  Intuitively,
"link-local" doesn't make sense in this universe, it's rather "local
to your set of neighbours".

> protocol, you can implement DAD over that, but what about current

You're right, we don't do DAD.  That's related to the issues with
link-local above.

-- Juliusz

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 5 Jul 2013 10:49:49 +0900

> You're right, we don't do DAD.  That's related to the issues with

I see. So this is a significant change in semantics. Given that RFC 2462
says:

   Duplicate Address Detection MUST be performed on all unicast
   addresses prior to assigning them to an interface, regardless of
   whether they are obtained through stateless autoconfiguration,
   DHCPv6, or manual configuration, with the following exceptions:

then it's fair to expect that standard implementations can (and likely do)
assume that if DAD succeeds, then their IPv6 address is unique and usable.

That being the case, how can you ensure that there are no duplicate
addresses in the network? If all hosts on the nework speak the routing
protocol, then that's easy, but what about legacy hosts? Does this scheme
require that all hosts on the network speak the routing protocol?

---

From: Henning Rogge <[email-masked]>
Date: Fri, 5 Jul 2013 07:31:35 +0200

the DAD as defined in the IPv6 RFCs doesn't work in a multihop radio
network, because of the hidden station problem.

Imagine a situation with three nodes A, B and C. A can hear B, B can
hear A and C, C can hear B.

If A and C choose the same address, DAD will not detect the problem
because A and C cannot talk to each other directly, but B will have
two neighbors with the same address.

Because of this problem you need a different approach to generate your
addresses.

Henning Rogge

On Fri, Jul 5, 2013 at 3:49 AM, Lorenzo Colitti <[email-masked]> wrote:
> On Fri, Jul 5, 2013 at 2:35 AM, Juliusz Chroboczek
> <[email-masked]> wrote:
>>
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

-- 
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

---

From: Andrew McGregor <[email-masked]>
Date: Fri, 5 Jul 2013 16:02:01 +1000

DAD could be interpreted to mean, not the specific method defined in the
IPv6 RFCs, but 'some way of detecting duplicate addresses that is likely to
work in this situation'.

However, given that DAD as deployed doesn't work due to hidden nodes, this
becomes an extra requirement on APs and other wireless devices to help out
the DAD process. Presumably we need homenet routers, especially the
wireless ones, to proxy DAD when they know an address exists on any link,
whether or not there's an expectation that the two hosts could communicate
directly.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 5 Jul 2013 16:53:34 +0900

> IPv6 RFCs, but 'some way of detecting duplicate addresses that is likely to

Where "work in this situation" means "works without modifying existing host
implementations", yes?

---

From: Tim Chown <[email-masked]>
Date: Mon, 15 Jul 2013 12:14:33 +0100

On 17 Jun 2013, at 17:45, Michael Thomas <[email-masked]> wrote:

> First off, i have to say that 3.7 is much improved. it's been really hard to correlate my feedback from the
> lack of response to my initial last call comments from the editors.
> 
> 1) 3.7.1
> 
>   I still think that the intro could use more motivation from the problem space before jumping in
>   and proclaiming that users will choose from some gui. It's sort of the heart of why any of this is
>   important. It might be nice here or in section 3.7 to have some ascii art too showing the various
>   elements (cer repository, isp/cloud dns names, announcers/mdns'ers, local names, global names, tunnels)
>   to have something to point at.

I think this would be useful in the more-specific work to follow.

> 2) "In practice
>   however the underlying service discovery protocols should be capable
>   of handling moving to a network where a new device is using the same
>   name as a device used previously in another homenet."
> 
> I don't understand why they should be capable? What is the reason?

To avoid re-use of possibly previously cached/"bookmarked" information (stated in sentence above).

> 3) 3.7.8.  Devices roaming from the homenet
> 
> This is a new section and perhaps it's my fault, but isn't it a restatement that globally
> accessible names need to be part of the global dns? Or is this the "vpn"-like situation where
> I can see my local name space by virtue of having tunnelled back in? If the latter, it might
> be worthwhile to contrast it with global naming so as to make it more clear.

It could be both.  Added a sentence.

> 4) 3.7.3
> 
> Much better, but I'm still sort of uncomfortable about whether we really want the ulqdn name.
> It's been proposed, but it's not been very fleshed out, and I for one am not certain whether it
> means that I a) might have to type one in or b) have to look at the uldqn suffix to differentiate.
> It's not clear whether this document is the appropriate place to decide that, as I mentioned.

It probably isn't; this should be refined by more-specific work to follow, including probably the dnssdext BoF/WG.

> 5) 3.7.4
> 
> Much improved. I like it a lot. Might it be better to move 3.7.8 if it's the latter interpretation
> into this section? This section is talking about local naming, and it seems that talking about
> tunnelling to see that naming might be appropriate here? (which was my mobility feedback).

I think it's OK as is.

> 6) 3.7.6
> 
> I still think it would be better to write this in terms of battery rather than specific networking
> technology. It speaks to the actual problem rather than one specific case.

Battery is one problem. Constrained messaging is another. We have a pointer to CoAP for example.

> 7) 3.7.7
> 
> I still don't understand what this section is trying to highlight. Is there a piece of code here
> that needs to be written or not? I'm sorry if I'm being dense.

This is about a host learning its own DNS resolver to use, when nested behind multiple routers. Jari pointed this out after his own homenet experiments.

Tim

> Mike

---

From: mike <[email-masked]>
Date: Mon, 15 Jul 2013 08:49:30 -0700

> This is about a host learning its own DNS resolver to use, when nested behind multiple routers. Jari pointed this out after his own homenet experiments.
This section might be opening the split horizon can of worms. Homes may in
fact be subdivideable with, say, "Bobby's Room, Mom's Yankee Workshop", etc. So
is there a single go-to naming authority? I think the answer is unfortunately no,
especially when you consider that mDNS is its own creature.

What the solution to this is, I'm not certain but it may be worth pointing out in the arch
document to highlight that it is both out there and unresolved.

Mike

---

From: mike <[email-masked]>
Date: Tue, 16 Jul 2013 08:02:43 -0700

> especially when you consider that mDNS is its own creature.

  I should clarify that I mean that there may be different sources of "authority"
in a home. Whether that could or should be a harmonized into a single point of
contact for hosts is part of the solution space. I can see a single resolver on an
elected router be the go-to server even for mdns resolved names, which would
have some advantages from a policy standpoint, if nothing else. (eg, my guestnet
automatically loses on a naming collision with my main network regardless of
discovery or repository).

Mike

---

From: Tim Chown <[email-masked]>
Date: Wed, 17 Jul 2013 08:46:40 +0100

> discovery or repository).

This is something that I'm sure will be discussed within the dnssdext context, for which there's a BoF in Berlin.  The BoF is making the case for a WG at this stage though, so while some discussion of the requirements draft(s) is useful, it won't be diving into solutions yet.

I think the architecture text says enough; we could always add more and more details, but the steer from the chairs is to agree on the general principles, and then do the more-specific work. The issue Jari raised from his own homenet experiment was about propagating DNS resolver information through a routed infrastructure. That might be via a DHCPv6 relay (which would presumably mean routers need to learn where to relay to) or by using something (which may or may not be a routing protocol) to distribute such configuration information around the homenet. Or perhaps an external name service may be discovered through a zeroconf discovery protocol. But these are all options for future discussion.

I believe -09 is being passed to the IESG.

Tim

---

From: Ray Bellis <[email-masked]>
Date: Thu, 18 Jul 2013 11:57:23 +0000

> I believe -09 is being passed to the IESG.

That's the intent.

Mark and I still have to satisfy ourselves that WG Consensus has been reached, and then we'll do the document write-up before requesting publication.

kind regards,

Ray

---

From: Mark Townsley <[email-masked]>
Date: Sun, 28 Jul 2013 14:35:53 +0200

Ray and I have satisfied ourselves that consensus has been reached.  We will be working on the writeup this week and will pass it on to our AD shortly.

Many thanks for all the hard work and review, and special thanks to Tim for handling the bulk of the editing. Tim will present the final changes he made during the most recent Last Call at the start of the homenet session tomorrow. 

- Mark