Subject: [homenet] Homenet protocol decisions

From: Ole Troan <[email-masked]>
Date: Thu, 30 Jan 2014 11:48:35 +0100

All,

Updating the ospf prefix-assingment draft has been on my todo list for a long time.
Before doing so I wanted to ask the working group if there was any clear direction evolving.
Any views on the decisions in the flow chart attached? Anything I missed?

To summarize:
We need to decide, if we want prefix assignment and distribution of other configuration information integrated in a routing protocol. Depending on that decision we either need to design a separate protocol to do that, or we need to add support for that in a routing protocol. Prefix assignment is simpler with a link-state protocol, so that's why I have limited the choice of routing protocols for that branch. I have assumed there is agreement to have a single routing protocol in the home, and not support multiple.

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 30 Jan 2014 11:57:54 +0100

Hi,

I am also interested in this direction.

Thanks for the diagram, it illustrates well.

'Tightly couple routing protocol and prefix assignment, as well as
  distribution of other configuration information'?  (yes/no)

Yes.

But,

In my understanding, there is a need to couple the prefix assignment to 
the routing protocol.  Although I am not sure how much tight, or what 
tight and loose might mean.

For example, would coupling the DHCP-PD assignment operations triggering 
routing protocol updates mean tight or loose coupling.  Or would this be 
a 100% alternative to a routing protocol-only prefix assignment solution?

I am asking because I author an inidividual draft
draft-petrescu-relay-route-pd-problem-00.txt
"Route Problem at Relay during DHCPv6 Prefix Delegation" in this space.

Alex

Le 30/01/2014 11:48, Ole Troan a écrit :
> We need to decide, if we want prefix assignment and distribution of
> other configuration information integrated in a routing protocol.
> Depending on that decision we either need to design a separate protocol
> to do that, or we need to add support for that in a routing protocol.
> Prefix assignment is simpler with a link-state protocol, so that's why I
> have limited the choice of routing protocols for that branch. I have
> assumed there is agreement to have a single routing protocol in the
> home, and not support multiple.
>
> cheers,
> Ole
>
>
>
>
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Ole Troan <[email-masked]>
Date: Thu, 30 Jan 2014 12:04:52 +0100

> In my understanding, there is a need to couple the prefix assignment to the routing protocol.  Although I am not sure how much tight, or what tight and loose might mean.

to clarify what I meant:
tight coupling  --- integrated in a routing protocol, e.g. in draft-arkko-homenet-prefix-assignment
loosely coupled --- separate (new) protocol

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 30 Jan 2014 12:11:29 +0100

> loosely coupled --- separate (new) protocol

Could it be separate (existing) protocol?

Alex

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 30 Jan 2014 13:31:48 +0200

> Could it be separate (existing) protocol?

Given that it fulfills requirements, yes. I’m not aware of one, though. Off the cuff requirements follow:

- ~distributed database across network (=every node acts on same information, at least with some delay; some pruning may be possible for some cases, but not much; for simplification I’d say same information everywhere)

- precedence mechanism for sorting out conflicts among participating nodes

- information about neighbors on local link(s) (and preferably also some precedence function for deciding e.g. who needs to do DHCPv4 server duties if supporting IPv4)

Given node == router in this use case, it smells a lot like link state routing protocol to me. Has someone defined one without routing functionality as such? 

Cheers,

-Markus

---

From: Ole Troan <[email-masked]>
Date: Thu, 30 Jan 2014 12:35:23 +0100

Alex,

> Could it be separate (existing) protocol?

if one had existed, sure.
requirements from homenet-arch (I might have missed some):
 - must support multi-homing
 - each link should be assigned a stable prefix
 - efficient allocation of prefixes
 - should support both IPv4 and IPv6

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 30 Jan 2014 13:23:09 +0100

>   - should support both IPv4 and IPv6

I meant this:

loosely coupled ---- separate (existing DHCPv6-PD) protocol triggering
                      route updates to the routing protocol.

Alex

---

From: Ole Troan <[email-masked]>
Date: Thu, 30 Jan 2014 13:28:34 +0100

>                     route updates to the routing protocol.

yes, DHCP PD comes up as a proposed solution quite frequently.
I just don't see how you can make DHCP PD fulfill the requirements.

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 30 Jan 2014 13:38:02 +0100

> I just don't see how you can make DHCP PD fulfill the requirements.

Well it does support multi-homing (Server allocates things to as many 
interfaces as needed), each link can be assigned a stable prefix 
(provided it triggers updates to the Routing protocol), the allocation 
is efficient (Server maintains dynamic databases, leases) and it 
supports both IPv4 ('IPv4 subnet allocation' RFC6656, DHCP transition et 
alia), and IPv6.

I miss something?

Alex

---

From: Pierre Pfister <[email-masked]>
Date: Thu, 30 Jan 2014 13:46:25 +0100

Le 30 janv. 2014 à 13:38, Alexandru Petrescu <[email-masked]> a écrit :

> Well it does support multi-homing (Server allocates things to as many interfaces as needed), each link can be assigned a stable prefix (provided it triggers updates to the Routing protocol), the allocation is efficient (Server maintains dynamic databases, leases) and it supports both IPv4 ('IPv4 subnet allocation' RFC6656, DHCP transition et alia), and IPv6.
> 
> I miss something?

Well, in some cases DHCP seems to work, but not when you start imagining multi-homed networks with multiple routers. Or maybe you can tell me how to solve this situation with DHCP:

You have ISP1 connected with Router 1. ISP2 connected with Router 2. Router 1, Router 2, and a third Router (Router 3), are connected on the same link. 
ISP1 is delegated the prefix A/56 to Router 1. ISP2 is delegating the prefix B/56 to Router 2.

A host is connected behind Router 3. How can it get addresses from both prefixes ?

Cheers,

Pierre

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 30 Jan 2014 13:55:13 +0100

Pierre,

Thanks for the reply.

Le 30/01/2014 13:46, Pierre Pfister a écrit :
>>>>> if one had existed, sure. requirements from homenet-arch (I
>>>>> might have missed some): - must support multi-homing - each
>>>>> link should be assigned a stable prefix - efficient
>>>>> allocation of prefixes - should support both IPv4 and IPv6
>>>>
>>>> I meant this:
>>>>
>>>> loosely coupled ---- separate (existing DHCPv6-PD) protocol
>>>> triggering route updates to the routing protocol.
>>>
>>> yes, DHCP PD comes up as a proposed solution quite frequently. I
>>> just don't see how you can make DHCP PD fulfill the
>>> requirements.
>>
>> Well it does support multi-homing (Server allocates things to as
>> many interfaces as needed), each link can be assigned a stable
>> prefix (provided it triggers updates to the Routing protocol), the
>> allocation is efficient (Server maintains dynamic databases,
>> leases) and it supports both IPv4 ('IPv4 subnet allocation'
>> RFC6656, DHCP transition et alia), and IPv6.
>>
>> I miss something?
>
> Well, in some cases DHCP seems to work, but not when you start
> imagining multi-homed networks with multiple routers. Or maybe you
> can tell me how to solve this situation with DHCP:
>
> You have ISP1 connected with Router 1. ISP2 connected with Router 2.
> Router 1, Router 2, and a third Router (Router 3), are connected on
> the same link. ISP1 is delegated the prefix A/56 to Router 1. ISP2
> is delegating the prefix B/56 to Router 2.
>
> A host is connected behind Router 3.

Bear with me for a moment... is this topology what you meant?

       ISP1               ISP2
        |                  |
     +-------+          +-------+
     |Router1|A/56      |Router2|B/56
     +-------+          +-------+
        |                  |
      --+-------+----------+--
                |
                |
            +-------+
            |Router3|
            +-------+
                |
              +----+
              |Host|(how can it get an address from A, and from B)
              +----+

> How can it get addresses from both prefixes ?

Before I try to figure it out - is the above topology what is meant? 
Something I misplaced?

Alex

>
> Cheers,
>
> Pierre
>
>
>>
>> Alex
>>
>>>
>>> cheers, Ole
>>>
>>
>>
>> _______________________________________________ homenet mailing
>> list [email-masked]

---

From: Pierre Pfister <[email-masked]>
Date: Thu, 30 Jan 2014 14:01:19 +0100

Le 30 janv. 2014 à 13:55, Alexandru Petrescu <[email-masked]> a écrit :

> Before I try to figure it out - is the above topology what is meant? Something I misplaced?

It is correct. 

Pierre

---

From: Ole Troan <[email-masked]>
Date: Thu, 30 Jan 2014 14:03:32 +0100

Alex,

changing the thread since this seems to diverge from getting answers to the questions I asked.

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 30 Jan 2014 14:18:44 +0100 (CET)

> home, and not support multiple.

I agree with the decision chart.

While I initially was very enthusiastic about integrating prefix 
assignment into a routing protocol, I am now more sceptic to this 
approach.

So question if we don't use the routing protocol for prefix assignment, 
what should go in there? Should we have a new protocol for service 
discovery? Topology discovery? Anything else? Anyhow, the src/dst 
enhancements for the IGP has to be done, I don't see much alternative to 
that.

Anyhow, I don't think DHCPv6-PD is a good method to assign prefixes to 
interfaces.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Branimir Rajtar <[email-masked]>
Date: Thu, 30 Jan 2014 15:53:54 +0100

Hi all,

I would like to clarify what is meant by "distribution of other
configuration information"? We're all talking about distributing prefixes,
but what about SIP and similar configuration parameters? In my opinion,
it's not something I would like to see being distributed in OSPF/IS-IS.
It's just not something routing protocols should be doing.

That being said, the alternative option is to define a new protocol... Over
the last year, I've been playing with the idea of a protocol that uses the
DNS idea of recursion (and discussing it with a couple of people). Let me
clarify with the example of a SIP server:
1. we have a SIP server at the ISP
2. my home has 7 cascaded HGWs and none of them know the address of the SIP
server
3. I want to connect my analogue phone to the sixth HGW and so this HGW
needs to find out the SIP server address - he therefore asks his upstream
HGW (the fifth in line) for it (of course, using this new and fancy
protocol)
4. the fifth doesn't know it and asks the fourth, the fourth asks the
third, etc.
5. the first one (the one connected to the ISP) gets the request and
requests the ISP via DHCPv6 for it
6. upon receipt, the first forwards the information to the second, the
second tells the third, etc. until the 6th receives it and then I can use
my phone

This approach would have to be worked on (what about multiple upstream
links, routing loops?), but I like it. It could be extended to support the
delegation of prefixes, active detection of "border" HGWs (when do you send
out DHCPv6?)...

Any thoughts?

Branimir

On Thu, Jan 30, 2014 at 2:18 PM, Mikael Abrahamsson <[email-masked]>wrote:

>  We need to decide, if we want prefix assignment and distribution of other
>> configuration information integrated in a routing protocol. Depending on
>> that decision we either need to design a separate protocol to do that, or
>> we need to add support for that in a routing protocol. Prefix assignment is
>> simpler with a link-state protocol, so that's why I have limited the choice
>> of routing protocols for that branch. I have assumed there is agreement to
>> have a single routing protocol in the home, and not support multiple.
>>
>
> assignment into a routing protocol, I am now more sceptic to this approach.
>

---

From: Dave Taht <[email-masked]>
Date: Thu, 30 Jan 2014 07:50:52 -0800

>> configuration information integrated in a routing protocol. Depending on

don't want it in the routing protocol.

>> that decision we either need to design a separate protocol to do that, or we
>> need to add support for that in a routing protocol.

>> Prefix assignment is
>> simpler with a link-state protocol,

I don't have any love for link-state personally.

> so that's why I have limited the choice

I'm interested only in a routing protocol that works well with wired, wireless,
and the internet of things.

I don't think anyone will ever agree to a single routing protocol decision
unless the protocol meets those requirements well, and is battle tested
to meet those requirements well. And none do.

> While I initially was very enthusiastic about integrating prefix assignment
> into a routing protocol, I am now more sceptic to this approach.

I was unenthusiastic, (as are the maintainers of every routing daemon
I know of) and wanted to leverage ahcpd's methods (if not
necessarily the existing version of the protocol) of propagating info,
pre-routing information.

> So question if we don't use the routing protocol for prefix assignment, what
> should go in there? Should we have a new protocol for service discovery?

It is my hope that hybrid-proxy-mdns solves this. Certainly mdns is pretty
good about picking up dynamically changed

> Topology discovery? Anything else? Anyhow, the src/dst enhancements for the
> IGP has to be done, I don't see much alternative to that.

src/dst support landed in openwrt Barrier Breaker and cerowrt a week
or two back.
(it's still kind of rough). I also finally got up on comcast ipv6 personally.

In addition to src/dst semi-solving a raft of problems (bcp38 for ipv6
anyone?), it exposed others
like

-1) Getting a swarm of RA's from upstream triggered a firewall reload
every few seconds,
     which took a few seconds to reload, leading to an unusable ipv6
implementation.

   (if you are running cerowrt or openwrt on comcast DO upgrade. Ghu help you if
    you are merely on an "ipv6 certified" router)

0) comcast is only distributing a /60.

It still seems that being able to distribute and route between /128s is needed,
and nd proxying for folk that are only doing a /64 and have subnets.

1) in the multi-homing case you want requests from a local dns server
to be sourced
    from the right network to the right ISP-provided forwarder. (think
I have a fix for
    that but it involves abandoning resolv.conf for specific dnsmasq
configuration.

2) most vpn technologies are not aware of src/dst routing decisions and routing
    protocols can route around them, mistakenly. (tried strongswan so far)

3) Boy do we need to be able to forcibly retract ips and routes after
a reboot and
    acquisition of a new subnet and loss of an old.

   The only way I can see clear to doing this is to support some form
of authentication.
   "I got this subnet from this source, and now it's telling me to
retract it in favor of
    this subnet"

4) the vast increase in ipv6 related multicast led me to finally
violate the 802.11 standard and
    fix wireless multicast rates to 9mbits. So far that hasn't broken anything.

> Anyhow, I don't think DHCPv6-PD is a good method to assign prefixes to

Well, it works on the edge gateway, not so much on interior.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 30 Jan 2014 18:46:14 +0200

On 30.1.2014, at 17.50, Dave Taht <[email-masked]> wrote:
> don’t want it in the routing protocol.

Why not? You can stick in kitchen sink there! ;-)

> to meet those requirements well. And none do.

The definition of ‘works’ varies by people, so by that definition, I don’t think there is much to see here.

> good about picking up dynamically changed

hybrid proxy fixes some things ( see https://github.com/sbyx/ohybridproxy for a minimalist implementation that seems to work, more or less ). However, it needs quite a bit of configuration on top of that that you can’t squeeze in easily; or at least, you wind up with either

- configuration coming from some other protocol (like my old OSPF+SD draft), or
- dns-updates + god DNS server + god DNS server replication within your home

I’m not sure which is worse, but neither sounds very appealing.

> and nd proxying for folk that are only doing a /64 and have subnets.

Lots of nodes still don’t do stateful DHCPv6 (and even fewer do AHCP or something else); obviously, we could just ignore them and point at RFC6434? Hmm.

>    that but it involves abandoning resolv.conf for specific dnsmasq

Does it really work without host changes? Let’s assume you have prefixes A and B from ISPs ISP_A, ISP_B. You have host that has addresses in A and B. It chooses to point it’s upstream resolver at your dnsmasq on your router. How do you figure which upstream DNS server to use? A and B source address won’t help in this case, as DNS resolution is done with ‘point SOMETHING at configured DNS server’ in most current hosts.

>    fix wireless multicast rates to 9mbits. So far that hasn’t broken anything.

Oho. Do you have concrete numbers on how much multicast you’re seeing in and what sort of topology? Just base IPv6 stuff or e.g. mdns?

Cheers,

-Markus

---

From: Dave Taht <[email-masked]>
Date: Thu, 30 Jan 2014 09:30:42 -0800

On Thu, Jan 30, 2014 at 8:46 AM, Markus Stenberg <[email-masked]> wrote:
> The definition of 'works' varies by people, so by that definition, I don't think there is much to see here.

Much work is required here, and co-ordination with the wgs on internet
of things would make sense.

And running code, in upstream versions of the relevant daemons.

> hybrid proxy fixes some things ( see https://github.com/sbyx/ohybridproxy for a minimalist implementation that seems to work, more or less ). However, it needs quite a bit of configuration on top of that that you can't squeeze in easily; or at least, you wind up with either
>
> I'm not sure which is worse, but neither sounds very appealing.

Yep, we need a replacement for dns, that is replicable (uses a dht?),
robust, and secure. Anyone?

> Lots of nodes still don't do stateful DHCPv6 (and even fewer do AHCP or something else); obviously, we could just ignore them and point at RFC6434? Hmm.

I don't mind pushing people at the standards at all :) I never grokked
much of the overall emphasis on distributing /64s everywhere though.

the problem I've long had to deal with is only getting a single /64 at
best in a routed network (and /60 doesn't help much either).

ahcp has and has been for 6 years on linux

apt-get install babeld # pulls in ahcp
edit /etc/default/ahcpd to add your interfaces and specify -6 only
edit /etc/ahcp/ahcp-script.sh # to more sanely add servers

walla. you get /128s.

dhcpv6 is similar, of course. Presently openwrt is handing out /128s
for stateful dhcpv6, I don't know if that's intended.

> Does it really work without host changes? Let's assume you have prefixes A and B from ISPs ISP_A,

yes.

>ISP_B. You have host that has addresses in A and B. It chooses to point it's upstream resolver at your dnsmasq on your router. How do you figure which upstream DNS server to use? A and B source address won't help in this case, as DNS resolution is done with 'point SOMETHING at configured DNS server' in most current hosts.

in-home hosts can point to any local dns server over any ip address
type, be it ipv4, link local, ula, or some set of ISP provided
address.

on the gateway the local dns server needs to distinguish from what ISP
was derived the relevant source
addresses, so it can issue queries to an upstream dns server, which
involves abandoning leveraging
/etc/resolv.conf.auto, for a dnsmasq specific configuration:

cat /tmp/dnsmasq.d/comcast.conf
server=2001:558:feed::1@260x:y:z::1
server=2001:558:feed::2@260x:y:z::1

Bind also can do the same, but the syntax is more involved.

The in-home dns server also needs to ensure it only responds to
queries from internal hosts (so as not to become a open resolver),
presently that's done by ignoring queries from the external
interface(s). It would
be nice if queries from external hosts for the AAAA records for your
in-home domain worked. Are there
any dynamic dns providers working with AAAAs yet?

incidentally one thing that could be used specifically for dns is to
give the server it's own ipv6
address to play in, thus freeing up all ports to protect against
things like the kaminsky attack, and
better being able to correctly handle queries from the universe.
Another option is run dns on
a separate box, which conceptually hands the address awareness problem
back to some sort of protocol.

(Personally I see a lot of homes not running a local dns server and
relying on mdns internally instead.)

I was very happy to start routing all my dns traffic over ipv6
recently, in saving udp4 ports for
other uses. The impact of running a local dnsrbl can drop
significantly if NXDOMAIN is honored
by the upstream server. I merely turned off getting ISP nameservers
via dhcp4 and get them from
dhcpv6 on the gateway.

I have proposed syntax for dealing with reverse lookups to the
dnsmasq-discuss list.

> Oho. Do you have concrete numbers on how much multicast you're seeing in and what sort of topology? Just base IPv6 stuff or e.g. mdns?

What I have at the moment is indirectly observable effects

-- 
Dave Täht

---

From: Ole Troan <[email-masked]>
Date: Thu, 30 Jan 2014 22:04:59 +0100

> I would like to clarify what is meant by "distribution of other configuration information"? We're all talking about distributing prefixes, but what about SIP and similar configuration parameters? In my opinion, it's not something I would like to see being distributed in OSPF/IS-IS. It's just not something routing protocols should be doing.

by other configuration information I was thinking of two types of information:
 - information that is required by the other routers in the home network.
   e.g. zone information required for hybrid mDNS proxies
 - information that is passed around to the routers, and then passed on to the hosts using RA or DHCP:
   e.g. DNS recursive resolvers, DNS server selection policy, SAS/DAS selection policy

I think there is an important 'scoping' here. the mechanisms here should be used to configure the function of the routers in the home network, and pass information to the hosts to configure the _network_ layer.

I don't quite see how you can (or should) configure applications this way.

cheers,
Ole

> 
> That being said, the alternative option is to define a new protocol... Over the last year, I've been playing with the idea of a protocol that uses the DNS idea of recursion (and discussing it with a couple of people). Let me clarify with the example of a SIP server:
> 2. my home has 7 cascaded HGWs and none of them know the address of the SIP server
> 3. I want to connect my analogue phone to the sixth HGW and so this HGW needs to find out the SIP server address - he therefore asks his upstream HGW (the fifth in line) for it (of course, using this new and fancy protocol)
> 4. the fifth doesn't know it and asks the fourth, the fourth asks the third, etc.
> 5. the first one (the one connected to the ISP) gets the request and requests the ISP via DHCPv6 for it
> 6. upon receipt, the first forwards the information to the second, the second tells the third, etc. until the 6th receives it and then I can use my phone
> 
> This approach would have to be worked on (what about multiple upstream links, routing loops?), but I like it. It could be extended to support the delegation of prefixes, active detection of "border" HGWs (when do you send out DHCPv6?)...
> 
> Any thoughts?
> 
> Branimir
> 
> 
> 
> On Thu, Jan 30, 2014 at 2:18 PM, Mikael Abrahamsson <[email-masked]> wrote:
> While I initially was very enthusiastic about integrating prefix assignment into a routing protocol, I am now more sceptic to this approach.
> 
> So question if we don't use the routing protocol for prefix assignment, what should go in there? Should we have a new protocol for service discovery? Topology discovery? Anything else? Anyhow, the src/dst enhancements for the IGP has to be done, I don't see much alternative to that.
> 
> Anyhow, I don't think DHCPv6-PD is a good method to assign prefixes to interfaces.
> 
> --

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 Jan 2014 13:13:55 -0800

On Thu, Jan 30, 2014 at 2:48 AM, Ole Troan <[email-masked]> wrote:

> configuration information integrated in a routing protocol.
>

I think the two should be in the same protocol, because routing and
addressing are tightly coupled. Fundamentally, there is no point in
configuring an address on a host if the homenet doesn't have reachability
to it - because you can't use that address to talk to anyone else in the
homenet.

If the routing protocol and the prefix distribution protocol are separate,
then they can end up with different ideas on what prefix is on a given
link. That will lead to blackholing.

---

From: Ole Troan <[email-masked]>
Date: Thu, 30 Jan 2014 22:17:37 +0100

Dave,

>    that but it involves abandoning resolv.conf for specific dnsmasq

I can't quite see how you can do that. given that typically the DNS lookup is done prior
to the choice of source address (choice of outgoing link).

RFC6731 specifies a policy that can be distributed to hosts. (which would typically go in a homenet protocol).
 it is unfortunate that in some VPN / walled garden scenarios there are split DNS, if it wasn't this wouldn't have been a problem.

I'm unsure what the right answer is with regards to using recursive resolvers outside of your own administrative domain.
DNS forwarders make an attractive target for surveillance.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Jan 2014 10:43:09 +1300

>  - should support both IPv4 and IPv6

I think you need to add
 - must allow source-address-based next hop routing
 - must support multiple prefixes per subnet
 - must guarantee consistency with routing

(The last one doesn't mean "must be provided by routing protocol",
but it does mean that whatever box generates the PD message
MUST be configured with the same information as the routers.)

And also
 - must be zero-conf as far as the end user is concerned

I actually don't see how to separate this discussion (PD)
from the discussion about how to announce multiple
first-hop (a.k.a. default) routers.

I also don't see how to separate it from the discussion
of autonomic networking that is starting in NMRG, because
of the zero-conf requirement.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Thu, 30 Jan 2014 22:53:53 +0100

Brian,

> - must allow source-address-based next hop routing

care to elaborate why you think so?
in my mind addressing != routing

> - must support multiple prefixes per subnet

yes, multiple "site prefixes", multiple assignments from the same site-prefix should be avoided though.

> MUST be configured with the same information as the routers.)

absolutely.

> - must be zero-conf as far as the end user is concerned

yes. in the flow-chart I have that as "auto conf"

> first-hop (a.k.a. default) routers.

I'm not quite sure what you mean by "announce multiple first-hop routers".
is it different than the multihoming support requirement?
with regards to terminology. I prefer prefix assignment (PA). and use delegation when the process is between different administrative domains.

> of the zero-conf requirement.

possibly. there are a few autonomic related drafts submitted to homenet already. as far as I can see they are about building trusted adjacencies. (which could be a prerequisite for prefix assignment).

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Jan 2014 11:04:08 +1300

> in my mind addressing != routing

Well, it probably doesn't belong here, but we may need
different first hops to reach different exit routers
in the general case. However, yes, it's not needed as
part of PD itself.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Fri, 31 Jan 2014 10:14:15 +1100

In message <[email-masked]>
, Dave Taht writes:
> On Thu, Jan 30, 2014 at 8:46 AM, Markus Stenberg <[email-masked]> w=
> rote:
> >>>> of routing protocols for that branch. I have assumed there is agreemen=
> t to
> >> I'm interested only in a routing protocol that works well with wired, wi=
> reless,
> >> I don't think anyone will ever agree to a single routing protocol decisi=
> on
> > The definition of 'works' varies by people, so by that definition, I don'=
> t think there is much to see here.
> 
> >>> So question if we don't use the routing protocol for prefix assignment,=
>  what
> >> It is my hope that hybrid-proxy-mdns solves this. Certainly mdns is pret=
> ty
> > hybrid proxy fixes some things ( see https://github.com/sbyx/ohybridproxy=
>  for a minimalist implementation that seems to work, more or less ). Howeve=
> r, it needs quite a bit of configuration on top of that that you can't sque=
> eze in easily; or at least, you wind up with either
> >
> > - configuration coming from some other protocol (like my old OSPF+SD draf=
> t), or
> > - dns-updates + god DNS server + god DNS server replication within your h=
> ome
> >
> >> It still seems that being able to distribute and route between /128s is =
> needed,
> > Lots of nodes still don't do stateful DHCPv6 (and even fewer do AHCP or s=
> omething else); obviously, we could just ignore them and point at RFC6434? =
> Hmm.
> 
> > Does it really work without host changes? Let's assume you have prefixes =
> A and B from ISPs ISP_A,
> 
> yes.
> 
> >ISP_B. You have host that has addresses in A and B. It chooses to point it=
> 's upstream resolver at your dnsmasq on your router. How do you figure whic=
> h upstream DNS server to use? A and B source address won't help in this cas=
> e, as DNS resolution is done with 'point SOMETHING at configured DNS server=
> ' in most current hosts.
> 
> server=3D2001:558:feed::1@260x:y:z::1
> server=3D2001:558:feed::2@260x:y:z::1
> 

	forwarders {
		2001:558:feed::1; 2001:6000:feed::2;
	};

	server 2001:558:feed::1 {
		query-source 2001:558:xxxx::2;
	};

	server 2001:6000:feed::2 {
		query-source 2001:6000:xxxx::2;
	};

The server clauses could be removed if there was a way for the ISP
to say which prefixes it has so that the stack's source address
selection rules picked the prefix from that ISP for those addresses.

Presumably the ISP's recursive servers arn't open to the world.

> >>    fix wireless multicast rates to 9mbits. So far that hasn't broken any=
> thing.
> >
> > Oho. Do you have concrete numbers on how much multicast you're seeing in =
> and what sort of topology? Just base IPv6 stuff or e.g. mdns?
> 
> -- =
> Dave T=E4ht
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.=
> html
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Dave Taht <[email-masked]>
Date: Thu, 30 Jan 2014 18:59:40 -0500

>                 query-source 2001:6000:xxxx::2;

excellent.

> selection rules picked the prefix from that ISP for those addresses.

How about reverse lookups?

-- 
Dave Täht

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 31 Jan 2014 09:37:15 +0100 (CET)

On Thu, 30 Jan 2014, Lorenzo Colitti wrote:

> If the routing protocol and the prefix distribution protocol are 
> separate, then they can end up with different ideas on what prefix is on 
> a given link. That will lead to blackholing.

I don't agree.

I think a valid approach is to have a separate protocol set the address on 
an interface which is then picked up by the routing protocol and 
redistributed just like if it was manually configured.

Routing protocol deamons normally don't set interface IP addresses, they 
carry de-facto information they get from other places and the only thing 
they update is the RIB/FIB in the machine.

So to continue this, even carrying service discovery information leads to 
new information flow in that the routing protocol now needs to update a 
service discovery "Information Base". At least this is less intrusive than 
having it set interface IP addresses.

---

From: Teco Boot <[email-masked]>
Date: Fri, 31 Jan 2014 09:57:33 +0100

+1

I can see reasons for having shared sub-layer for routing protocol and prefix distribution protocol. As example, in MANET we have such already: RFC 5444 and 5498. If we define a set of TLVs for border router information and prefix distribution, it can run on whatever routing protocol. Don't forget BGP.

For Homenet plug&play, I don't suggest to let configure grandma her favorite IGP ;)

Teco

Op 31 jan. 2014, om 09:37 heeft Mikael Abrahamsson <[email-masked]> het volgende geschreven:

>> If the routing protocol and the prefix distribution protocol are separate, then they can end up with different ideas on what prefix is on a given link. That will lead to blackholing.
> 
> I don't agree.
> 
> I think a valid approach is to have a separate protocol set the address on an interface which is then picked up by the routing protocol and redistributed just like if it was manually configured.
> 
> Routing protocol deamons normally don't set interface IP addresses, they carry de-facto information they get from other places and the only thing they update is the RIB/FIB in the machine.
> 
> So to continue this, even carrying service discovery information leads to new information flow in that the routing protocol now needs to update a service discovery "Information Base". At least this is less intrusive than having it set interface IP addresses.
> 
> --

---

From: Ole Troan <[email-masked]>
Date: Fri, 31 Jan 2014 09:56:20 +0100

Teco,

> For Homenet plug&play, I don't suggest to let configure grandma her favorite IGP ;)

doesn't that mean we have to pick one?

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 31 Jan 2014 10:16:33 +0100

Mikael,

> So to continue this, even carrying service discovery information leads to new information flow in that the routing protocol now needs to update a service discovery "Information Base". At least this…

there is another choice to make here.
either the homenet 'control' protocol floods service discovery records, or it is used only to boot strap an  independent service discovery mechanism.

the hybrid mDNS proxy is an implementation using the latter approach.

SD has turned out to be a lot harder to solve than at least I thought it would be.

cheers,
Ole

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 31 Jan 2014 12:12:45 +0200

> SD has turned out to be a lot harder to solve than at least I thought it would be.

SD would be much more trivial to solve if we allowed host changes, or at least would write about desired features there. E.g. no mDNS, just use DNS-SD[1] or something equally clever, and then you would have really consistent database of active services across the network that routers could share, or could have god DNS server, or something else (dtath’s DHT perhaps).

3.1.2 doesn’t sound very promising on that front (or the hundreds of millions of fruity logo compatible devices that mostly do mDNS and consider that all SD they ever need; then again, wonder how many of them do IPv6, or more specifically, non-linklocal IPv6).

Cheers,

-Markus

[1] with insecure dns-update (RFC2136) and allowing only updating records are related pertain to your IP{v4,v6} address and some sort of expiration logic based on your L2 presence it might work reasonably well?

---

From: Teco Boot <[email-masked]>
Date: Fri, 31 Jan 2014 12:37:54 +0100

> doesn't that mean we have to pick one?

At least one, for Homenet. Could be OSPF for high speed links, RPL for LLN, or OLSRv2 for mix of wireless and wired links including ad hoc radio links.

There is something common on prefix distribution in Homenet, small office/home office networks, branch office networks, ad hoc networks and even in enterprise / campus networks. The prefix distribution protocol could be a single protocol. We better not try to converge to a single routing protocol.

Teco

---

From: Ole Troan <[email-masked]>
Date: Fri, 31 Jan 2014 12:36:54 +0100

> There is something common on prefix distribution in Homenet, small office/home office networks, branch office networks, ad hoc networks and even in enterprise / campus networks. The prefix distribu…

how do you do a self-organizing / zero-conf network without making a choice?

cheers,
Ole

---

From: Brian Haberman <[email-masked]>
Date: Fri, 31 Jan 2014 08:53:11 -0500

Speaking as an interested observer only...

On 1/31/14 3:57 AM, Teco Boot wrote:
> +1
> 
> I can see reasons for having shared sub-layer for routing protocol
> and prefix distribution protocol. As example, in MANET we have such
> already: RFC 5444 and 5498. If we define a set of TLVs for border
> router information and prefix distribution, it can run on whatever
> routing protocol. Don't forget BGP.
> 

Yes, let's not forget BGP (but probably not for the reasons Teco
mentions it).  Many folks have expressed regrets over the years with the
amount of extra baggage that has been added to BGP.  Most of the time,
the argument for adding this non-routing stuff is that the distribution
model is the same.  The results have been less than stellar, IMO.

However, we have to consider that the rate of information update for
reachability is not the same as the update rate for prefix delegation.
Will the transport of that extra information lead to performance issues,
incompatibility with other devices speaking the same protocol, or
concerns over the security model needed for these two different functions?

Just food for thought.

Regards,
Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 Jan 2014 08:58:12 -0500

> At least one, for Homenet. Could be OSPF for high speed links, RPL for
    > LLN, or OLSRv2 for mix of wireless and wired links including ad hoc
    > radio links.

Lest people worry about who is going to configure all of this,  I want to
point out that actually each of these protocols run in networks different
security profiles.

That is, the set of links running OSPF in Homenet are mostly equivalent
security/trust-wise (taking into account that Fred and his wife will have
tweaked things to live with their seperate corporate policies).

The links running RPL are part of the Home *Automation* Network, and
depending upon who is doing things, may be less or more trusted than the OSPF
parts (probably, also depending upon your point of view).  There will be
routers/firewalls that speak Homenet/OSPF on one side and RPL on the other.

Ditto for the OLSRv2/AODV/Babel adhoc running links: they are essentially
alternative "uplinks", which from the Homenet point of view are weird
wall-free walled gardens. (Hanging gardens?
http://en.wikipedia.org/wiki/Hanging_Gardens_of_Babylon note tower of babeld
in the background)

====

I've asked that we come to some decision about how we are going to make the
protocol decision.  It's been dragging on for over a year now.

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 31 Jan 2014 18:08:50 +0100

Le 30/01/2014 22:13, Lorenzo Colitti a écrit :
> On Thu, Jan 30, 2014 at 2:48 AM, Ole Troan <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> configuring an address on a host if the homenet doesn't have
> reachability to it - because you can't use that address to talk to
> anyone else in the homenet.

(just a little point here, because I am encouraged by the beginning of 
the paragraph; yes, you can use a topologically incorrect address as src 
in outgoing packets, there are video stream applications for that; they 
  work especially in the small setting of home, where there's no ingress 
filtering).

> a given link. That will lead to blackholing.

I tend to agree, modulo exception above.  And provided I udnerstand the 
word 'blackholing'...

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 31 Jan 2014 18:12:37 +0100

> doesn't that mean we have to pick one?

Yes, and here's my preferred: pick DHCP, it satisfies all requirements; 
where it doesnt update it.  Then plug it into OSPF, then onto BGP.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 31 Jan 2014 09:13:07 -0800

> redistributed just like if it was manually configured.

And what happens when the routing protocol finds out that, even though the
delegation protocol thinks everything is OK and addresses were delegated
just fine, the network is now partitioned? How do you reassign addresses in
that case?

How do you tell the prefix assignment protocol that it needs to resolve
addressing conflicts when you merge two networks that have the same
prefixes? You have to tightly couple prefix assignment and routing again.
In which case it's just better to have the same protocol.

> they update is the RIB/FIB in the machine.

Yes, but in that case the responsibility for getting IP addresses correct
and non-overlapping falls on the operator. A self-organizing network
doesn't have an operator.

> service discovery "Information Base".

That's different. The assumption at the service layer is that below it, the
network will figure out routing and addressing, and packets either get to
the destination or they don't. What you're talking about is to have two
strongly coupled things in the networking layer (addressing and routing) be
run by separate protocols.

---

From: Teco Boot <[email-masked]>
Date: Fri, 31 Jan 2014 19:31:35 +0100

> how do you do a self-organizing / zero-conf network without making a choice?

I ment: We better not try to converge to a single routing protocol for Homenet, small office/home office networks, branch office networks, ad hoc networks and enterprise / campus networks.

If distributed info semantics for prefix distribution are well defined, it doesn't matter how it is delivered. Single encoding method helps, it is not absolutely required. If a box faces two routing domains, it redistributes. With DV style of flooding, this is simple and straightforward.

I still believe hosts shall be informed of information on border routers / exit links and corresponding prefix information. And I prefer hosts shall not have a need to snoop routing packets for that. Using a NDP extension is a no-brainer for me.

So yes, Homenet shall select a single routing protocol for higher data rate links (next to LLN routing, that one is separate).
We can check how to run a prefix distribution protocol on top of routing, or use another carrier (e.g. NDP).

My opinion: put the prefix distribution protocol on top of NDP, so all nodes are informed.

Teco

---

From: Teco Boot <[email-masked]>
Date: Fri, 31 Jan 2014 19:54:11 +0100

Op 31 jan. 2014, om 18:13 heeft Lorenzo Colitti <[email-masked]> het volgende geschreven:

> On Fri, Jan 31, 2014 at 12:37 AM, Mikael Abrahamsson <[email-masked]> wrote:
> And what happens when the routing protocol finds out that, even though the delegation protocol thinks everything is OK and addresses were delegated just fine, the network is now partitioned? How do you reassign addresses in that case?

I don't see a problem. If the two partitions have border router(s), addresses for the prefixes for the connected border router keeps functioning. Prefixes for the disconnected border router(s) should be deprecated. Is is an internal function on the router, based on topology information and configured prefixes, provided by routing protocol and prefix distribution protocol.

> How do you tell the prefix assignment protocol that it needs to resolve addressing conflicts when you merge two networks that have the same prefixes?

First we have to verify if this can happen. My favorite is using DHCP-PD with server on CPE (edge) box (and elected box for ULA). This box should circumvent your scenario.

> You have to tightly couple prefix assignment and routing again. In which case it's just better to have the same protocol.

I can't follow your arguments.

> Yes, but in that case the responsibility for getting IP addresses correct and non-overlapping falls on the operator. A self-organizing network doesn't have an operator.

I can't see how strongly coupled routing protocol and prefix distribution protocol can help.

>  
>> So to continue this, even carrying service discovery information leads to new information flow in that the routing protocol now needs to update a service discovery "Information Base".
> 
> That's different. The assumption at the service layer is that below it, the network will figure out routing and addressing, and packets either get to the destination or they don't. What you're talking about is to have two strongly coupled things in the networking layer (addressing and routing) be run by separate protocols.

Yes, they are (strongly) related. That doesn't mean that they shall be processed by same protocol. Maybe better have two simple protocols, with minimal interaction. Both protocols will have their own life cycle.

Teco

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 31 Jan 2014 10:56:42 -0800

On Fri, Jan 31, 2014 at 10:54 AM, Teco Boot <[email-masked]> wrote:

> > And what happens when the routing protocol finds out that, even though
> the delegation protocol thinks everything is OK and addresses were
> delegated just fine, the network is now partitioned? How do you reassign
> addresses in that case?
>
> I don't see a problem. If the two partitions have border router(s),
> addresses for the prefixes for the connected border router keeps
> functioning. Prefixes for the disconnected border router(s) should be
> deprecated. Is is an internal function on the router, based on topology
> information and configured prefixes, provided by routing protocol and
> prefix distribution protocol.
>
> prefixes?
> First we have to verify if this can happen. My favorite is using DHCP-PD
> with server on CPE (edge) box (and elected box for ULA). This box should
> circumvent your scenario.

Er, *what*? You are aware that if you have a partition, one of the two
partitions will not be able to reach the DHCP server?

---

From: Ole Troan <[email-masked]>
Date: Fri, 31 Jan 2014 20:25:58 +0100

Teco,

> I ment: We better not try to converge to a single routing protocol for Homenet, small office/home office networks, branch office networks, ad hoc networks and enterprise / campus networks.

OK, but at least we can pick a single routing protocol for the home.

> If distributed info semantics for prefix distribution are well defined, it doesn't matter how it is delivered. Single encoding method helps, it is not absolutely required. If a box faces two routin…

right. but we don't have to specify that in this working group, or at least not now.

> My opinion: put the prefix distribution protocol on top of NDP, so all nodes are informed.

what are the arguments for involving hosts in the prefix assignment protocol?
as opposed the existing router to hosts protocols (ND/DHCP).

cheers,
Ole