From toke at toke.dk  Sun May  1 12:53:28 2016
From: toke at toke.dk (=?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?=)
Date: Sun, 01 May 2016 14:53:28 +0200
Subject: [Babel-users] Babel in Bird 1.6.0
In-Reply-To: <20160430224215.B83B5FCD5@mail.crfreenet.org> (Ondrej Zajicek's
 message of "Sun, 1 May 2016 00:42:16 +0200")
References: <85ba0983-cd51-955d-6186-c0726fd82309@network.cz>
 <20160429182443.A96DCFCD6@mail.crfreenet.org>
 <857B046F-5D7F-4A8A-8900-33054AC4847E@toke.dk>
 <20160430112218.GB18524@lud.polynome.dn42> <87inyzb5kn.fsf@toke.dk>
 <20160430224215.B83B5FCD5@mail.crfreenet.org>
Message-ID: <87h9ei9bxz.fsf@toke.dk>

Ondrej Zajicek <santiago at crfreenet.org> writes:

>> Right, yeah, the overflow check is done on the specified values not
>> their centisecond equivalents. Oops.
>
> IMHO the reasonable way would be to keep such values (intervals)
> internally in Babel native time units (centiseconds) and only convert
> to BIRD units when appropriate (when mixed with bird_clock_t values).

That would work. Also thought about using the expr_us mechanism in the
config parser code. However, both of those would break existing
configurations (not that there are many at this point; but the principle
remains). What is your policy on that?

Also, since we can't actually schedule things at a granularity finer
than seconds, setting a lower value would just result in announcing
deadlines we then cannot meet, which is bound to break things. So for
the time being I think keeping it the way it is would be best, no?

-Toke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20160501/f87d9051/attachment.sig>

From toke at toke.dk  Sun May  1 13:32:58 2016
From: toke at toke.dk (=?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?=)
Date: Sun, 01 May 2016 15:32:58 +0200
Subject: [Babel-users] Version 1.6.0
In-Reply-To: <20160430221924.1F5BAFCD5@mail.crfreenet.org> (Ondrej Zajicek's
 message of "Sun, 1 May 2016 00:19:24 +0200")
References: <85ba0983-cd51-955d-6186-c0726fd82309@network.cz>
 <20160429182443.A96DCFCD6@mail.crfreenet.org>
 <857B046F-5D7F-4A8A-8900-33054AC4847E@toke.dk>
 <20160430221924.1F5BAFCD5@mail.crfreenet.org>
Message-ID: <87d1p5aool.fsf@toke.dk>

Ondrej Zajicek <santiago at crfreenet.org> writes:

> Some comments to my changes. I originally thought that i would just do
> some minor formatting changes, but i end with some heavy code changes and
> plenty of bugfixes. Hopefully i did not make much more errors.

Thanks for the overview. Some comments below.

> Some issues i found and fixed (and noted down):
>
>  - modified ge_mod64k() still does not work:
>
>    static inline u16 ge_mod64k(u16 a, u16 b)
>    { return (a == b || b - a > 0x8000); }
>
>    Due to C integer promotion rules, b - a is computed in (signed) integers
>    and not in u16s, so if b = 1 and a = 2, you get -1, so > is false.
>    The solution is to use uint as the type for a, b, so it is computed in
>    unsigned integers and result can be safely typecasted to u16:
>
>    static inline int ge_mod64k(uint a, uint b)
>    { return (u16)(a - b) < 0x8000; }

Was wondering about this. Thanks for the explanation.

>  - in some cases (e.g. babel_handle_route_request()), check for plen == 0
>    or check if prefix is IPA_NONE is used where check for AE 0 should be
>    used instead. Note that these are two different cases - there is the
>    default route ::/0 (with AE 2), which is a regular route, and there is
>    'wildcard' AE 0, which represent all routes.

This was actually deliberate on my part: I have considered the different
AEs as solely a matter of encoding on the wire, and not carrying any
significance as to the semantics of the prefix. I.e. and update with AE
0 and no prefix and one with AE 2 encoding ::/0 are identical in my
reading.

If this is not the case, I think the RFC needs to specify what, exactly,
is meant by a "wildcard address". I've always thought of ::/0 as the
wildcard address; and doesn't "default route" also mean "wildcard
route"?

Either way, this probably needs to be specified somewhere.

>  - babel_read_update() - does BABEL_AE_IP6_LL make sense?

Not sure it makes much sense to announce a route for a link-local
address, but I suppose it could be used to set a router ID? (Not sure
why anyone would do that, but it would not technically be out of spec).

> Feel free to comment any of my changes.

No comments on the rest of the fixes, other than 'thanks for the
bugfixes'. Oh, thanks in general for your thorough review of the
different iterations of my patch series; it has definitely improved
things, and I have learned a lot about the idiosyncrasies of C :) 

> I found also some problems that were hard to fix and not severe,
> mainly related to route recalculation and triggered updates. These
> were left in the code. I will comment them later.

Okidoki, please do tell. I do believe there is some more work that can
be done to improve the route selection logic in the future; some sort of
hysteresis would probably be desirable, for instance.


I'll send a patch series fixing all the small issues we have accumulated
once I'm fairly certain that they are actually resolved. :)

-Toke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20160501/2d3bec50/attachment.sig>

From jch at pps.univ-paris-diderot.fr  Sun May  1 14:31:31 2016
From: jch at pps.univ-paris-diderot.fr (Juliusz Chroboczek)
Date: Sun, 01 May 2016 16:31:31 +0200
Subject: [Babel-users] Version 1.6.0
In-Reply-To: <87d1p5aool.fsf@toke.dk>
References: <85ba0983-cd51-955d-6186-c0726fd82309@network.cz>
 <20160429182443.A96DCFCD6@mail.crfreenet.org>
 <857B046F-5D7F-4A8A-8900-33054AC4847E@toke.dk>
 <20160430221924.1F5BAFCD5@mail.crfreenet.org>
 <87d1p5aool.fsf@toke.dk>
Message-ID: <87zis9g88s.wl-jch@pps.univ-paris-diderot.fr>

> If this is not the case, I think the RFC needs to specify what, exactly,
> is meant by a "wildcard address". I've always thought of ::/0 as the
> wildcard address; and doesn't "default route" also mean "wildcard
> route"?

Wow, no.

The main purpose of a routing protocol is to carry prefixes.  Now prefixes
do represent sets of addresses, but that's none of the routing protocol's
business -- from the point of view of the protocol, they are just opaque
constructs.

For example, a request for 2000::/3 requests an update for 2000::/3.  If
a router has routers for 2000::/4 and 3000::/4 but no route for 2000::/3,
it must not use the longer prefixes to satisfy a request for 2000::/3 --
from the router's point of view, there's no relation between the prefixes.

AE 0 is used to mean "any" in the following circumstances:

  - IHU (where it represents "any" interface identifier);
  - non-seqno request (where it represents "any" prefix);
  - retraction (where it represents "any" prefix).

It is not allowed in any other place -- in other places, RFC 6126 says
that AE MUST NOT be 0.  (There's an omission in Section 4.4.9, where it
only says in what case AE MAY be 0; the implication is that it MUST NOT be
0 in other cases.)

If we decide to make an incompatible revision of Babel, I might decide to
remove AE 0.  While it seemed like a good idea at the time, it's turned
out to only be moderately useful -- the retraction case can be handled by
announcing a Hell interval of 10ms (which causes the neighbour to drop
after 0.16s), and the other uses are not useful.

-- Juliusz


From santiago at crfreenet.org  Sun May  1 14:42:03 2016
From: santiago at crfreenet.org (Ondrej Zajicek)
Date: Sun, 1 May 2016 16:42:03 +0200
Subject: [Babel-users] Version 1.6.0
In-Reply-To: <87d1p5aool.fsf@toke.dk>
References: <85ba0983-cd51-955d-6186-c0726fd82309@network.cz>
 <20160429182443.A96DCFCD6@mail.crfreenet.org>
 <857B046F-5D7F-4A8A-8900-33054AC4847E@toke.dk>
 <20160430221924.1F5BAFCD5@mail.crfreenet.org>
 <87d1p5aool.fsf@toke.dk>
Message-ID: <20160501144203.20483FD04@mail.crfreenet.org>

On Sun, May 01, 2016 at 03:32:58PM +0200, Toke H?iland-J?rgensen wrote:
> Ondrej Zajicek <santiago at crfreenet.org> writes:
> 
> >  - in some cases (e.g. babel_handle_route_request()), check for plen == 0
> >    or check if prefix is IPA_NONE is used where check for AE 0 should be
> >    used instead. Note that these are two different cases - there is the
> >    default route ::/0 (with AE 2), which is a regular route, and there is
> >    'wildcard' AE 0, which represent all routes.
> 
> This was actually deliberate on my part: I have considered the different
> AEs as solely a matter of encoding on the wire, and not carrying any
> significance as to the semantics of the prefix. I.e. and update with AE
> 0 and no prefix and one with AE 2 encoding ::/0 are identical in my
> reading.

There is an implied semantics of address family:

   The address family of an address is either IPv4 or IPv6; it is
   undefined for AE 0, IPv4 for AE 1, and IPv6 for AE 2 and 3.

Obviously, there is a difference between AE 1 encoding 0.0.0.0/0 and
AE 2 encoding ::/0, therefore AE 0 cannot be identical to both of them.


> If this is not the case, I think the RFC needs to specify what, exactly,
> is meant by a "wildcard address". I've always thought of ::/0 as the
> wildcard address; and doesn't "default route" also mean "wildcard
> route"?

'default route' is just a name for the least specific route, i.e. 0.0.0.0/0
or ::/0, but it is a route like any other. While meaning of AE 0 is more
like unspecified/any route. Its exact meaning depends on specific TLV:

IHU TLV (address implied/irrelevant):

  it MAY be 0 if the TLV is sent to a unicast address, if the association
  is over a point-to-point link, or when bidirectional reachability is 
  ascertained by means outside of the Babel protocol.

Update TLV (all routes):

  AE MAY then be 0, in which case this Update retracts all of the routes
  previously advertised on this interface.

Route Request TLV (all routes):

  The (AE) value 0 specifies that this is a request for a full routing
  table dump (a wildcard request)


> >  - babel_read_update() - does BABEL_AE_IP6_LL make sense?
> 
> Not sure it makes much sense to announce a route for a link-local
> address, but I suppose it could be used to set a router ID? (Not sure
> why anyone would do that, but it would not technically be out of spec).

Well, most routing protocols explicitly forbid to propagate link-local
routes. So this may be omission in RFC 6126, OTOH it might make sense
on ad-hoc wireless networks, where everybody is in one network but there
is no full mutual visibily.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20160501/2c7868c9/attachment.sig>

From toke at toke.dk  Sun May  1 15:36:21 2016
From: toke at toke.dk (=?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?=)
Date: Sun, 01 May 2016 17:36:21 +0200
Subject: [Babel-users] Version 1.6.0
In-Reply-To: <87zis9g88s.wl-jch@pps.univ-paris-diderot.fr> (Juliusz
 Chroboczek's message of "Sun, 01 May 2016 16:31:31 +0200")
References: <85ba0983-cd51-955d-6186-c0726fd82309@network.cz>
 <20160429182443.A96DCFCD6@mail.crfreenet.org>
 <857B046F-5D7F-4A8A-8900-33054AC4847E@toke.dk>
 <20160430221924.1F5BAFCD5@mail.crfreenet.org> <87d1p5aool.fsf@toke.dk>
 <87zis9g88s.wl-jch@pps.univ-paris-diderot.fr>
Message-ID: <878tztaiyy.fsf@toke.dk>

Juliusz Chroboczek <jch at pps.univ-paris-diderot.fr> writes:

>> If this is not the case, I think the RFC needs to specify what,
>> exactly, is meant by a "wildcard address". I've always thought of
>> ::/0 as the wildcard address; and doesn't "default route" also mean
>> "wildcard route"?
>
> Wow, no.

Yes, feel free to marvel at my ignorance ;)

> For example, a request for 2000::/3 requests an update for 2000::/3.
> If a router has routers for 2000::/4 and 3000::/4 but no route for
> 2000::/3, it must not use the longer prefixes to satisfy a request for
> 2000::/3 -- from the router's point of view, there's no relation
> between the prefixes.

That I did know.

> AE 0 is used to mean "any" in the following circumstances:
>
>   - IHU (where it represents "any" interface identifier);
>   - non-seqno request (where it represents "any" prefix);
>   - retraction (where it represents "any" prefix).
>
> It is not allowed in any other place -- in other places, RFC 6126 says
> that AE MUST NOT be 0. (There's an omission in Section 4.4.9, where it
> only says in what case AE MAY be 0; the implication is that it MUST
> NOT be 0 in other cases.)

Hmm, maybe this should be spelled out somewhere? Otherwise you'll just
have problems with people unfamiliar with such basic constructs of
routing protocols trying to implement the protocol; who knows where that
might lead? :)

> If we decide to make an incompatible revision of Babel, I might decide
> to remove AE 0. While it seemed like a good idea at the time, it's
> turned out to only be moderately useful -- the retraction case can be
> handled by announcing a Hell interval of 10ms (which causes the
> neighbour to drop after 0.16s), and the other uses are not useful.

Fine with me :)

-Toke


From toke at toke.dk  Sun May  1 15:37:03 2016
From: toke at toke.dk (=?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?=)
Date: Sun, 01 May 2016 17:37:03 +0200
Subject: [Babel-users] Version 1.6.0
In-Reply-To: <20160501144203.20483FD04@mail.crfreenet.org> (Ondrej Zajicek's
 message of "Sun, 1 May 2016 16:42:03 +0200")
References: <85ba0983-cd51-955d-6186-c0726fd82309@network.cz>
 <20160429182443.A96DCFCD6@mail.crfreenet.org>
 <857B046F-5D7F-4A8A-8900-33054AC4847E@toke.dk>
 <20160430221924.1F5BAFCD5@mail.crfreenet.org> <87d1p5aool.fsf@toke.dk>
 <20160501144203.20483FD04@mail.crfreenet.org>
Message-ID: <874mahaixs.fsf@toke.dk>

Ondrej Zajicek <santiago at crfreenet.org> writes:

> On Sun, May 01, 2016 at 03:32:58PM +0200, Toke H?iland-J?rgensen wrote:
>> Ondrej Zajicek <santiago at crfreenet.org> writes:
>> 
>> >  - in some cases (e.g. babel_handle_route_request()), check for plen == 0
>> >    or check if prefix is IPA_NONE is used where check for AE 0 should be
>> >    used instead. Note that these are two different cases - there is the
>> >    default route ::/0 (with AE 2), which is a regular route, and there is
>> >    'wildcard' AE 0, which represent all routes.
>> 
>> This was actually deliberate on my part: I have considered the different
>> AEs as solely a matter of encoding on the wire, and not carrying any
>> significance as to the semantics of the prefix. I.e. and update with AE
>> 0 and no prefix and one with AE 2 encoding ::/0 are identical in my
>> reading.
>
> There is an implied semantics of address family:
>
>    The address family of an address is either IPv4 or IPv6; it is
>    undefined for AE 0, IPv4 for AE 1, and IPv6 for AE 2 and 3.
>
> Obviously, there is a difference between AE 1 encoding 0.0.0.0/0 and
> AE 2 encoding ::/0, therefore AE 0 cannot be identical to both of
> them.

Now that you mention it, I do remember wondering about that... Makes
sense :)

-Toke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20160501/f1f544fa/attachment-0001.sig>

From v.tolstov at selfip.ru  Sun May  1 17:51:39 2016
From: v.tolstov at selfip.ru (Vasiliy Tolstov)
Date: Sun, 1 May 2016 20:51:39 +0300
Subject: [Babel-users] Babel in Bird 1.6.0
In-Reply-To: <87h9ei9bxz.fsf@toke.dk>
References: <85ba0983-cd51-955d-6186-c0726fd82309@network.cz>
 <20160429182443.A96DCFCD6@mail.crfreenet.org>
 <857B046F-5D7F-4A8A-8900-33054AC4847E@toke.dk>
 <20160430112218.GB18524@lud.polynome.dn42> <87inyzb5kn.fsf@toke.dk>
 <20160430224215.B83B5FCD5@mail.crfreenet.org>
 <87h9ei9bxz.fsf@toke.dk>
Message-ID: <CACaajQs0Dtcp4ooUEgba+i==aiNgis=UrCF6oYBTJ_T2EZqyKw@mail.gmail.com>

Do you have plans in near feature create ipv4 support?in this case I can
drop bird and use only bird6 for ipv4/ipv6 routes inside my network.
1 ??? 2016 ?. 16:14 ???????????? "Toke H?iland-J?rgensen" <toke at toke.dk>
???????:

> Ondrej Zajicek <santiago at crfreenet.org> writes:
>
> >> Right, yeah, the overflow check is done on the specified values not
> >> their centisecond equivalents. Oops.
> >
> > IMHO the reasonable way would be to keep such values (intervals)
> > internally in Babel native time units (centiseconds) and only convert
> > to BIRD units when appropriate (when mixed with bird_clock_t values).
>
> That would work. Also thought about using the expr_us mechanism in the
> config parser code. However, both of those would break existing
> configurations (not that there are many at this point; but the principle
> remains). What is your policy on that?
>
> Also, since we can't actually schedule things at a granularity finer
> than seconds, setting a lower value would just result in announcing
> deadlines we then cannot meet, which is bound to break things. So for
> the time being I think keeping it the way it is would be best, no?
>
> -Toke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20160501/72d04253/attachment.html>

From toke at toke.dk  Sun May  1 18:09:20 2016
From: toke at toke.dk (=?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?=)
Date: Sun, 01 May 2016 20:09:20 +0200
Subject: [Babel-users] Babel in Bird 1.6.0
In-Reply-To: <CACaajQs0Dtcp4ooUEgba+i==aiNgis=UrCF6oYBTJ_T2EZqyKw@mail.gmail.com>
 (Vasiliy Tolstov's message of "Sun, 1 May 2016 20:51:39 +0300")
References: <85ba0983-cd51-955d-6186-c0726fd82309@network.cz>
 <20160429182443.A96DCFCD6@mail.crfreenet.org>
 <857B046F-5D7F-4A8A-8900-33054AC4847E@toke.dk>
 <20160430112218.GB18524@lud.polynome.dn42> <87inyzb5kn.fsf@toke.dk>
 <20160430224215.B83B5FCD5@mail.crfreenet.org> <87h9ei9bxz.fsf@toke.dk>
 <CACaajQs0Dtcp4ooUEgba+i==aiNgis=UrCF6oYBTJ_T2EZqyKw@mail.gmail.com>
Message-ID: <87zis98xbj.fsf@toke.dk>

Vasiliy Tolstov <v.tolstov at selfip.ru> writes:

> Do you have plans in near feature create ipv4 support?in this case I
> can drop bird and use only bird6 for ipv4/ipv6 routes inside my
> network.

Would love to, but that requires dual-stack support in Bird core. AFAIK
there are plans to support this eventually, but Ondrej can probably
answer that better than me... :)

-Toke


From jch at pps.univ-paris-diderot.fr  Sun May  1 21:38:28 2016
From: jch at pps.univ-paris-diderot.fr (Juliusz Chroboczek)
Date: Sun, 01 May 2016 23:38:28 +0200
Subject: [Babel-users] Version 1.6.0
In-Reply-To: <878tztaiyy.fsf@toke.dk>
References: <85ba0983-cd51-955d-6186-c0726fd82309@network.cz>
 <20160429182443.A96DCFCD6@mail.crfreenet.org>
 <857B046F-5D7F-4A8A-8900-33054AC4847E@toke.dk>
 <20160430221924.1F5BAFCD5@mail.crfreenet.org>
 <87d1p5aool.fsf@toke.dk>
 <87zis9g88s.wl-jch@pps.univ-paris-diderot.fr>
 <878tztaiyy.fsf@toke.dk>
Message-ID: <87vb2xfoh7.wl-jch@pps.univ-paris-diderot.fr>

>> It is not allowed in any other place -- in other places, RFC 6126 says
>> that AE MUST NOT be 0. (There's an omission in Section 4.4.9, where it
>> only says in what case AE MAY be 0; the implication is that it MUST
>> NOT be 0 in other cases.)

> Hmm, maybe this should be spelled out somewhere?

Could you please clarify what exactly needs to be spelled out?  I have the
impression that the meaning of AE 0 is spelled out pretty clearly in all
three pleaces where it is allowed.  The one missing bit is Updates, where
it doesn't state clearly that AE 0 is only allowed for retractions, but
I think it's pretty clear from context.

-- Juliusz


From toke at toke.dk  Sun May  1 22:03:28 2016
From: toke at toke.dk (=?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?=)
Date: Mon, 02 May 2016 00:03:28 +0200
Subject: [Babel-users] Version 1.6.0
In-Reply-To: <87vb2xfoh7.wl-jch@pps.univ-paris-diderot.fr> (Juliusz
 Chroboczek's message of "Sun, 01 May 2016 23:38:28 +0200")
References: <85ba0983-cd51-955d-6186-c0726fd82309@network.cz>
 <20160429182443.A96DCFCD6@mail.crfreenet.org>
 <857B046F-5D7F-4A8A-8900-33054AC4847E@toke.dk>
 <20160430221924.1F5BAFCD5@mail.crfreenet.org> <87d1p5aool.fsf@toke.dk>
 <87zis9g88s.wl-jch@pps.univ-paris-diderot.fr> <878tztaiyy.fsf@toke.dk>
 <87vb2xfoh7.wl-jch@pps.univ-paris-diderot.fr>
Message-ID: <87vb2x8mhb.fsf@toke.dk>

Juliusz Chroboczek <jch at pps.univ-paris-diderot.fr> writes:

>> Hmm, maybe this should be spelled out somewhere?
>
> Could you please clarify what exactly needs to be spelled out? I have
> the impression that the meaning of AE 0 is spelled out pretty clearly
> in all three pleaces where it is allowed. The one missing bit is
> Updates, where it doesn't state clearly that AE 0 is only allowed for
> retractions, but I think it's pretty clear from context.

It's not *when* the field should be set to 0 that is unclear, but rather
that this changes the semantics so that the TLV no longer encodes a
prefix, but rather turns into a wildcard request.

Adding some text to that effect could be done in section 4.1.3, for
instance. I.e. instead of writing:

   o  AE 0: wildcard address.  The value is 0 octets long.

one could write something along the lines of:

   o  AE 0: wildcard address. The value is 0 octets long. When this is
   set, the TLV does not encode a prefix, but rather contains a wildcard
   request.



Not sure if this is the right place to do it, or if this should be done
in section 2 or 3 instead (where the description is more conceptual).
But I think it was the term 'wildcard address' with no further
explanation that sent me down the wrong track.

-Toke


From boutier at pps.univ-paris-diderot.fr  Mon May  2 08:56:35 2016
From: boutier at pps.univ-paris-diderot.fr (Matthieu Boutier)
Date: Mon,  2 May 2016 10:56:35 +0200
Subject: [Babel-users] [PATCH 3/3] Revert "Fix bug allowing the comparison
	of v4 and v6 prefixes."
In-Reply-To: <1462179395-5126-3-git-send-email-boutier@pps.univ-paris-diderot.fr>
References: <1462179395-5126-1-git-send-email-boutier@pps.univ-paris-diderot.fr>
 <1462179395-5126-2-git-send-email-boutier@pps.univ-paris-diderot.fr>
 <1462179395-5126-3-git-send-email-boutier@pps.univ-paris-diderot.fr>
Message-ID: <1462179395-5126-4-git-send-email-boutier@pps.univ-paris-diderot.fr>

That patch was fixing a little bug, but makes another bigger one.
The previous patch fixes both.

This reverts commit e687a58f01f2f1bcc344d8f9bacdfa5954dcae69.
---
 util.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/util.c b/util.c
index 1c15dbf..37b16ff 100644
--- a/util.c
+++ b/util.c
@@ -496,9 +496,6 @@ prefix_cmp(const unsigned char *p1, unsigned char plen1,
 {
     int plen = MIN(plen1, plen2);
 
-    if(v4mapped(p1) != v4mapped(p2))
-        return PST_DISJOINT;
-
     if(memcmp(p1, p2, plen / 8) != 0)
         return PST_DISJOINT;
 
-- 
2.8.0.rc3



From boutier at pps.univ-paris-diderot.fr  Mon May  2 08:56:33 2016
From: boutier at pps.univ-paris-diderot.fr (Matthieu Boutier)
Date: Mon,  2 May 2016 10:56:33 +0200
Subject: [Babel-users] [PATCH 1/3] Fix and simplify printing.
In-Reply-To: <1462179395-5126-1-git-send-email-boutier@pps.univ-paris-diderot.fr>
References: <1462179395-5126-1-git-send-email-boutier@pps.univ-paris-diderot.fr>
Message-ID: <1462179395-5126-2-git-send-email-boutier@pps.univ-paris-diderot.fr>

---
 route.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/route.c b/route.c
index 1a8d59f..0eacd00 100644
--- a/route.c
+++ b/route.c
@@ -850,15 +850,10 @@ update_route(const unsigned char *id,
     if(memcmp(id, myid, 8) == 0)
         return NULL;
 
-    if(martian_prefix(prefix, plen)) {
-        fprintf(stderr, "Rejecting martian route to %s through %s.\n",
-                format_prefix(prefix, plen), format_address(nexthop));
-        return NULL;
-    }
-    if(src_plen != 0 && martian_prefix(src_prefix, src_plen)) {
+    if(martian_prefix(prefix, plen) || martian_prefix(src_prefix, src_plen)) {
         fprintf(stderr, "Rejecting martian route to %s from %s through %s.\n",
                 format_prefix(prefix, plen),
-                format_prefix(src_prefix, src_plen), format_eui64(id));
+                format_prefix(src_prefix, src_plen), format_address(nexthop));
         return NULL;
     }
 
-- 
2.8.0.rc3



From boutier at pps.univ-paris-diderot.fr  Mon May  2 08:56:32 2016
From: boutier at pps.univ-paris-diderot.fr (Matthieu Boutier)
Date: Mon,  2 May 2016 10:56:32 +0200
Subject: [Babel-users] Normal source prefix encoding.
Message-ID: <1462179395-5126-1-git-send-email-boutier@pps.univ-paris-diderot.fr>

Default source prefixes were encoded with src_plen == 0, even in v4.  This
leads to some bugs (comparison between prefixes), and may be confusing for
long term maintenance.  Now, the condition to know if a route is source-
specific is handled by the new is_default() function, applied to the source
prefix of the route.



From boutier at pps.univ-paris-diderot.fr  Mon May  2 08:56:34 2016
From: boutier at pps.univ-paris-diderot.fr (Matthieu Boutier)
Date: Mon,  2 May 2016 10:56:34 +0200
Subject: [Babel-users] [PATCH 2/3] Use standard v4mapped encoding for source
	prefixes.
In-Reply-To: <1462179395-5126-2-git-send-email-boutier@pps.univ-paris-diderot.fr>
References: <1462179395-5126-1-git-send-email-boutier@pps.univ-paris-diderot.fr>
 <1462179395-5126-2-git-send-email-boutier@pps.univ-paris-diderot.fr>
Message-ID: <1462179395-5126-3-git-send-email-boutier@pps.univ-paris-diderot.fr>

---
 interface.h      |  2 +-
 kernel.h         |  2 +-
 kernel_netlink.c |  7 +++--
 kernel_socket.c  |  2 +-
 message.c        | 92 ++++++++++++++++++++++++++++++++++++--------------------
 route.c          | 19 ++++++------
 rule.c           |  2 +-
 util.h           |  6 ++++
 8 files changed, 82 insertions(+), 50 deletions(-)

diff --git a/interface.h b/interface.h
index 5d0eedd..97ad77d 100644
--- a/interface.h
+++ b/interface.h
@@ -25,7 +25,7 @@ struct buffered_update {
     unsigned char prefix[16];
     unsigned char src_prefix[16];
     unsigned char plen;
-    unsigned char src_plen; /* 0 <=> no src prefix */
+    unsigned char src_plen;
     unsigned char pad[2];
 };
 
diff --git a/kernel.h b/kernel.h
index b6286fc..5688d01 100644
--- a/kernel.h
+++ b/kernel.h
@@ -29,7 +29,7 @@ struct kernel_route {
     unsigned char prefix[16];
     int plen;
     unsigned char src_prefix[16];
-    int src_plen; /* no source prefix <=> src_plen == 0 */
+    int src_plen;
     int metric;
     unsigned int ifindex;
     int proto;
diff --git a/kernel_netlink.c b/kernel_netlink.c
index 4eadc39..30cc6fb 100644
--- a/kernel_netlink.c
+++ b/kernel_netlink.c
@@ -951,12 +951,12 @@ kernel_route(int operation, int table,
     /* Check that the protocol family is consistent. */
     if(plen >= 96 && v4mapped(dest)) {
         if(!v4mapped(gate) ||
-           (src_plen > 0 && (!v4mapped(src) || src_plen < 96))) {
+           !v4mapped(src)) {
             errno = EINVAL;
             return -1;
         }
     } else {
-        if(v4mapped(gate)|| (src_plen > 0 && v4mapped(src))) {
+        if(v4mapped(gate) || v4mapped(src)) {
             errno = EINVAL;
             return -1;
         }
@@ -991,7 +991,7 @@ kernel_route(int operation, int table,
 
 
     ipv4 = v4mapped(gate);
-    use_src = (src_plen != 0 && kernel_disambiguate(ipv4));
+    use_src = (!is_default(src, src_plen) && kernel_disambiguate(ipv4));
 
     kdebugf("kernel_route: %s %s from %s "
             "table %d metric %d dev %d nexthop %s\n",
@@ -1092,6 +1092,7 @@ parse_kernel_route_rta(struct rtmsg *rtm, int len, struct kernel_route *route)
         /* if RTA_DST is not a TLV, that's a default destination */
         const unsigned char zeroes[4] = {0, 0, 0, 0};
         v4tov6(route->prefix, zeroes);
+        v4tov6(route->src_prefix, zeroes);
         route->plen = 96;
     }
     route->proto = rtm->rtm_protocol;
diff --git a/kernel_socket.c b/kernel_socket.c
index 92ff93d..7b5419b 100644
--- a/kernel_socket.c
+++ b/kernel_socket.c
@@ -424,7 +424,7 @@ kernel_route(int operation, int table,
             0x00, 0x00, 0x00, 0x00, 0x7f, 0x00, 0x00, 0x01 }}};
 
     /* Source-specific routes are not implemented yet for BSD. */
-    if(src_plen > 0) {
+    if(!is_default(src, src_plen)) {
         errno = ENOSYS;
         return -1;
     }
diff --git a/message.c b/message.c
index fdc1999..a8d307c 100644
--- a/message.c
+++ b/message.c
@@ -443,8 +443,8 @@ parse_packet(const unsigned char *from, struct interface *ifp,
                 have_v6_nh = 1;
             }
         } else if(type == MESSAGE_UPDATE) {
-            unsigned char prefix[16], *nh;
-            unsigned char plen;
+            unsigned char prefix[16], src_prefix[16], *nh;
+            unsigned char plen, src_plen;
             unsigned char channels[MAX_CHANNEL_HOPS];
             int channels_len = MAX_CHANNEL_HOPS;
             unsigned short interval, seqno, metric;
@@ -465,6 +465,13 @@ parse_packet(const unsigned char *from, struct interface *ifp,
                                     len - 10, prefix);
             else
                 rc = -1;
+            if(message[2] == 1) {
+                v4tov6(src_prefix, zeroes);
+                src_plen = 96;
+            } else {
+                memcpy(src_prefix, zeroes, 16);
+                src_plen = 0;
+            }
             if(rc < 0) {
                 if(message[3] & 0x80)
                     have_v4_prefix = have_v6_prefix = 0;
@@ -527,11 +534,11 @@ parse_packet(const unsigned char *from, struct interface *ifp,
 
             parse_update_subtlv(ifp, metric, message + 2 + parsed_len,
                                 len - parsed_len, channels, &channels_len);
-            update_route(router_id, prefix, plen, zeroes, 0, seqno,
+            update_route(router_id, prefix, plen, src_prefix, src_plen, seqno,
                          metric, interval, neigh, nh,
                          channels, channels_len);
         } else if(type == MESSAGE_REQUEST) {
-            unsigned char prefix[16], plen;
+            unsigned char prefix[16], src_prefix[16], plen, src_plen;
             int rc;
             if(len < 2) goto fail;
             rc = network_prefix(message[2], message[3], 0,
@@ -553,10 +560,17 @@ parse_packet(const unsigned char *from, struct interface *ifp,
                    now.tv_sec - MAX(neigh->ifp->hello_interval / 100, 1))
                     send_update(neigh->ifp, 0, NULL, 0, zeroes, 0);
             } else {
-                send_update(neigh->ifp, 0, prefix, plen, zeroes, 0);
+                if(message[2] == 1) {
+                    v4tov6(src_prefix, zeroes);
+                    src_plen = 96;
+                } else {
+                    memcpy(src_prefix, zeroes, 16);
+                    src_plen = 0;
+                }
+                send_update(neigh->ifp, 0, prefix, plen, src_prefix, src_plen);
             }
         } else if(type == MESSAGE_MH_REQUEST) {
-            unsigned char prefix[16], plen;
+            unsigned char prefix[16], src_prefix[16], plen, src_plen;
             unsigned short seqno;
             int rc;
             if(len < 14) goto fail;
@@ -565,12 +579,19 @@ parse_packet(const unsigned char *from, struct interface *ifp,
                                 message + 16, NULL, len - 14, prefix);
             if(rc < 0) goto fail;
             plen = message[3] + (message[2] == 1 ? 96 : 0);
+            if(message[2] == 1) {
+                v4tov6(src_prefix, zeroes);
+                src_plen = 96;
+            } else {
+                memcpy(src_prefix, zeroes, 16);
+                src_plen = 0;
+            }
             debugf("Received request (%d) for %s from %s on %s (%s, %d).\n",
                    message[6],
                    format_prefix(prefix, plen),
                    format_address(from), ifp->name,
                    format_eui64(message + 8), seqno);
-            handle_request(neigh, prefix, plen, zeroes, 0, message[6],
+            handle_request(neigh, prefix, plen, src_prefix, src_plen, message[6],
                            seqno, message + 8);
         } else if(type == MESSAGE_UPDATE_SRC_SPECIFIC) {
             unsigned char prefix[16], src_prefix[16], *nh;
@@ -1121,6 +1142,7 @@ really_send_update(struct interface *ifp,
     int real_src_plen = 0;
     unsigned short flags = 0;
     int channels_size;
+    int no_src = is_default(src_prefix, src_plen);
 
     if(diversity_kind != DIVERSITY_CHANNEL)
         channels_len = -1;
@@ -1157,17 +1179,15 @@ really_send_update(struct interface *ifp,
 
         real_prefix = prefix + 12;
         real_plen = plen - 96;
-        if(src_plen != 0 /* it should never be 96 */) {
-            real_src_prefix = src_prefix + 12;
-            real_src_plen = src_plen - 96;
-        }
+        real_src_prefix = src_prefix + 12;
+        real_src_plen = src_plen - 96;
     } else {
         if(ifp->have_buffered_prefix) {
             while(omit < plen / 8 &&
                   ifp->buffered_prefix[omit] == prefix[omit])
                 omit++;
         }
-        if(src_plen == 0 && (!ifp->have_buffered_prefix || plen >= 48))
+        if(no_src && (!ifp->have_buffered_prefix || plen >= 48))
             flags |= 0x80;
         real_prefix = prefix;
         real_plen = plen;
@@ -1176,7 +1196,7 @@ really_send_update(struct interface *ifp,
     }
 
     if(!ifp->have_buffered_id || memcmp(id, ifp->buffered_id, 8) != 0) {
-        if(src_plen == 0 && real_plen == 128 &&
+        if(no_src && real_plen == 128 &&
            memcmp(real_prefix + 8, id, 8) == 0) {
             flags |= 0x40;
         } else {
@@ -1189,7 +1209,7 @@ really_send_update(struct interface *ifp,
         ifp->have_buffered_id = 1;
     }
 
-    if(src_plen == 0)
+    if(no_src)
         start_message(ifp, MESSAGE_UPDATE, 10 + (real_plen + 7) / 8 - omit +
                       channels_size);
     else
@@ -1197,7 +1217,7 @@ really_send_update(struct interface *ifp,
                       10 + (real_plen + 7) / 8 - omit +
                       (real_src_plen + 7) / 8 + channels_size);
     accumulate_byte(ifp, v4 ? 1 : 2);
-    if(src_plen != 0)
+    if(!no_src)
         accumulate_byte(ifp, real_src_plen);
     else
         accumulate_byte(ifp, flags);
@@ -1207,7 +1227,7 @@ really_send_update(struct interface *ifp,
     accumulate_short(ifp, seqno);
     accumulate_short(ifp, metric);
     accumulate_bytes(ifp, real_prefix + omit, (real_plen + 7) / 8 - omit);
-    if(src_plen != 0)
+    if(!no_src)
         accumulate_bytes(ifp, real_src_prefix, (real_src_plen + 7) / 8);
     /* Note that an empty channels TLV is different from no such TLV. */
     if(channels_len >= 0) {
@@ -1215,7 +1235,7 @@ really_send_update(struct interface *ifp,
         accumulate_byte(ifp, channels_len);
         accumulate_bytes(ifp, channels, channels_len);
     }
-    if(src_plen == 0)
+    if(no_src)
         end_message(ifp, MESSAGE_UPDATE, 10 + (real_plen + 7) / 8 - omit +
                     channels_size);
     else
@@ -1502,11 +1522,13 @@ send_update(struct interface *ifp, int urgent,
         routes = route_stream(ROUTE_INSTALLED);
         if(routes) {
             while(1) {
+                int no_src;
                 struct babel_route *route = route_stream_next(routes);
                 if(route == NULL)
                     break;
-                if((src_prefix && route->src->src_plen != 0) ||
-                   (prefix && route->src->src_plen == 0))
+                no_src = is_default(route->src->src_prefix,
+                                    route->src->src_plen);
+                if((src_prefix && !no_src) || (prefix && no_src))
                     continue;
                 buffer_update(ifp, route->src->prefix, route->src->plen,
                               route->src->src_prefix, route->src->src_plen);
@@ -1723,7 +1745,7 @@ send_request(struct interface *ifp,
              const unsigned char *prefix, unsigned char plen,
              const unsigned char *src_prefix, unsigned char src_plen)
 {
-    int v4, pb, spb, len;
+    int v4, pb, spb, len, no_src;
 
     if(ifp == NULL) {
         struct interface *ifp_auxn;
@@ -1770,7 +1792,8 @@ send_request(struct interface *ifp,
     pb = v4 ? ((plen - 96) + 7) / 8 : (plen + 7) / 8;
     len = 2 + pb;
 
-    if(src_plen != 0) {
+    no_src = is_default(src_prefix, src_plen);
+    if(!no_src) {
         spb = v4 ? ((src_plen - 96) + 7) / 8 : (src_plen + 7) / 8;
         len += spb + 1;
         start_message(ifp, MESSAGE_REQUEST_SRC_SPECIFIC, len);
@@ -1780,13 +1803,13 @@ send_request(struct interface *ifp,
     }
     accumulate_byte(ifp, v4 ? 1 : 2);
     accumulate_byte(ifp, v4 ? plen - 96 : plen);
-    if(src_plen != 0)
+    if(!no_src)
         accumulate_byte(ifp, v4 ? src_plen - 96 : src_plen);
     if(v4)
         accumulate_bytes(ifp, prefix + 12, pb);
     else
         accumulate_bytes(ifp, prefix, pb);
-    if(src_plen != 0) {
+    if(!no_src) {
         if(v4)
             accumulate_bytes(ifp, src_prefix + 12, spb);
         else
@@ -1802,7 +1825,7 @@ send_unicast_request(struct neighbour *neigh,
                      const unsigned char *prefix, unsigned char plen,
                      const unsigned char *src_prefix, unsigned char src_plen)
 {
-    int rc, v4, pb, spb, len;
+    int rc, v4, pb, spb, len, no_src;
 
     /* make sure any buffered updates go out before this request. */
     flushupdates(neigh->ifp);
@@ -1841,7 +1864,8 @@ send_unicast_request(struct neighbour *neigh,
     pb = v4 ? ((plen - 96) + 7) / 8 : (plen + 7) / 8;
     len = 2 + pb;
 
-    if(src_plen != 0) {
+    no_src = is_default(src_prefix, src_plen);
+    if(!no_src) {
         spb = v4 ? ((src_plen - 96) + 7) / 8 : (src_plen + 7) / 8;
         len += spb + 1;
         rc = start_unicast_message(neigh, MESSAGE_REQUEST_SRC_SPECIFIC, len);
@@ -1852,13 +1876,13 @@ send_unicast_request(struct neighbour *neigh,
     if(rc < 0) return;
     accumulate_unicast_byte(neigh, v4 ? 1 : 2);
     accumulate_unicast_byte(neigh, v4 ? plen - 96 : plen);
-    if(src_plen != 0)
+    if(!no_src)
         accumulate_unicast_byte(neigh, v4 ? src_plen - 96 : src_plen);
     if(v4)
         accumulate_unicast_bytes(neigh, prefix + 12, pb);
     else
         accumulate_unicast_bytes(neigh, prefix, pb);
-    if(src_plen != 0) {
+    if(!no_src) {
         if(v4)
             accumulate_unicast_bytes(neigh, src_prefix + 12, spb);
         else
@@ -1876,7 +1900,7 @@ send_multihop_request(struct interface *ifp,
                       unsigned short seqno, const unsigned char *id,
                       unsigned short hop_count)
 {
-    int v4, pb, spb, len;
+    int v4, pb, spb, len, no_src;
 
     /* Make sure any buffered updates go out before this request. */
     flushupdates(ifp);
@@ -1902,7 +1926,8 @@ send_multihop_request(struct interface *ifp,
     pb = v4 ? ((plen - 96) + 7) / 8 : (plen + 7) / 8;
     len = 6 + 8 + pb;
 
-    if(src_plen != 0) {
+    no_src = is_default(src_prefix, src_plen);
+    if(!no_src) {
         spb = v4 ? ((src_plen - 96) + 7) / 8 : (src_plen + 7) / 8;
         len += spb;
         start_message(ifp, MESSAGE_MH_REQUEST_SRC_SPECIFIC, len);
@@ -1922,7 +1947,7 @@ send_multihop_request(struct interface *ifp,
         else
             accumulate_bytes(ifp, prefix, pb);
     }
-    if(src_plen != 0) {
+    if(!no_src) {
         if(v4)
             accumulate_bytes(ifp, src_prefix + 12, spb);
         else
@@ -1941,7 +1966,7 @@ send_unicast_multihop_request(struct neighbour *neigh,
                               unsigned short seqno, const unsigned char *id,
                               unsigned short hop_count)
 {
-    int rc, v4, pb, spb, len;
+    int rc, v4, pb, spb, len, no_src;
 
     /* Make sure any buffered updates go out before this request. */
     flushupdates(neigh->ifp);
@@ -1954,7 +1979,8 @@ send_unicast_multihop_request(struct neighbour *neigh,
     pb = v4 ? ((plen - 96) + 7) / 8 : (plen + 7) / 8;
     len = 6 + 8 + pb;
 
-    if(src_plen != 0) {
+    no_src = is_default(src_prefix, src_plen);
+    if(!no_src) {
         spb = v4 ? ((src_plen - 96) + 7) / 8 : (src_plen + 7) / 8;
         len += spb;
         rc = start_unicast_message(neigh, MESSAGE_MH_REQUEST_SRC_SPECIFIC, len);
@@ -1975,7 +2001,7 @@ send_unicast_multihop_request(struct neighbour *neigh,
         else
             accumulate_unicast_bytes(neigh, prefix, pb);
     }
-    if(src_plen != 0) {
+    if(!no_src) {
         if(v4)
             accumulate_unicast_bytes(neigh, src_prefix + 12, spb);
         else
diff --git a/route.c b/route.c
index 0eacd00..2e8918e 100644
--- a/route.c
+++ b/route.c
@@ -59,7 +59,7 @@ check_specific_first(void)
     int specific = 1;
     int i;
     for(i = 0; i < route_slots; i++) {
-        if(routes[i]->src->src_plen == 0) {
+        if(is_default(routes[i]->src->src_prefix, routes[i]->src->src_plen)) {
             specific = 0;
         } else if(!specific) {
             return 0;
@@ -78,11 +78,13 @@ route_compare(const unsigned char *prefix, unsigned char plen,
               struct babel_route *route)
 {
     int i;
+    int no_src = is_default(src_prefix, src_plen);
+    int no_src_rt = is_default(route->src->src_prefix, route->src->src_plen);
 
     /* Put all source-specific routes in the front of the list. */
-    if(src_plen == 0 && route->src->src_plen > 0) {
+    if(no_src && !no_src_rt) {
         return 1;
-    } else if(src_plen > 0 && route->src->src_plen == 0) {
+    } else if(!no_src && no_src_rt) {
         return -1;
     }
 
@@ -95,10 +97,7 @@ route_compare(const unsigned char *prefix, unsigned char plen,
     if(plen > route->src->plen)
         return 1;
 
-    if(src_plen == 0) {
-        if(route->src->src_plen > 0)
-            return -1;
-    } else {
+    if(!no_src) {
         i = memcmp(src_prefix, route->src->src_prefix, 16);
         if(i != 0)
             return i;
@@ -401,7 +400,8 @@ route_stream_next(struct route_stream *stream)
     if(stream->installed) {
         while(stream->index < route_slots)
             if(stream->installed == ROUTE_SS_INSTALLED &&
-               routes[stream->index]->src->src_plen == 0)
+               is_default(routes[stream->index]->src->src_prefix,
+                          routes[stream->index]->src->src_plen))
                 return NULL;
             else if(routes[stream->index]->installed)
                 break;
@@ -858,10 +858,9 @@ update_route(const unsigned char *id,
     }
 
     is_v4 = v4mapped(prefix);
-    if(src_plen != 0 && is_v4 != v4mapped(src_prefix))
+    if(is_v4 != v4mapped(src_prefix))
         return NULL;
 
-
     add_metric = input_filter(id, prefix, plen, src_prefix, src_plen,
                               neigh->address, neigh->ifp->ifindex);
     if(add_metric >= INFINITY)
diff --git a/rule.c b/rule.c
index d8e826f..6f4de53 100644
--- a/rule.c
+++ b/rule.c
@@ -185,7 +185,7 @@ find_table(const unsigned char *dest, unsigned short plen,
     install_filter(dest, plen, src, src_plen, &filter_result);
     if(filter_result.table) {
         return filter_result.table;
-    } else if(src_plen == 0) {
+    } else if(is_default(src, src_plen)) {
         return export_table;
     } else if(kernel_disambiguate(v4mapped(dest))) {
         return export_table;
diff --git a/util.h b/util.h
index dd7bfb7..585bf7a 100644
--- a/util.h
+++ b/util.h
@@ -103,6 +103,12 @@ void v4tov6(unsigned char *dst, const unsigned char *src);
 int daemonise(void);
 int set_src_prefix(unsigned char *src_addr, unsigned char *src_plen);
 
+static inline int
+is_default(const unsigned char *prefix, int plen)
+{
+    return plen == 0 || (plen == 96 && v4mapped(prefix));
+}
+
 enum prefix_status {
     PST_EQUALS = 0,
     PST_DISJOINT,
-- 
2.8.0.rc3



From santiago at crfreenet.org  Mon May  2 13:38:18 2016
From: santiago at crfreenet.org (Ondrej Zajicek)
Date: Mon, 2 May 2016 15:38:18 +0200
Subject: [Babel-users] Babel in Bird
Message-ID: <20160502133818.D6AF6FCCF@mail.crfreenet.org>

Hi

During testing of Babel we noticed a strange behavior and we are not sure
if it is a problem in the implementation or in the specification.

The sequence of events is like:

1) Router A is running, originated some routes with seqno old_seqno and
propagated them to a router B.

2) If router A (or Babel protocol) is restarted, the seqno counter used for
originating routes is also reset to 1.

3) Then routes are originated with seqno 1 and propagated to router B.

4) Router B already has these routes with old high seqno, so the update
is considered unfeasible and for selected entries, so it is ignored
(3.5.4).

5) The routes in the router B's table slowly expire.

6) When routes expire, router B sends seqno request (3.8.2.1) with
old_seqno+1.

7) Router A receives seqno request, increases seqno to 2 (3.8.1.2),
originates routes with seqno 2 and sends them to router B.

8) Router B still ignores them as 2 < old_seqno.

9) Subsequent updates are still ignored as router B holds old
timeouted entry as a selected entry with unreachable metric
(as there is no other one) until GC time.


I have two questions w.r.t. this sequence of events:

1) How is router restart and seqnos supposed to be handled without
waiting for route timeout?

2) If a route is selected, then becomes unreachable/retracted, and there
is no other route to be selected, is it still considered selected? I
would say that no as the selection process (3.6) forbids retracted routes
to be selected, but the BIRD implementation keeps the old selected route
(now unreachable) in this case.


-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20160502/859c522d/attachment.sig>

From toke at toke.dk  Mon May  2 13:59:35 2016
From: toke at toke.dk (=?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?=)
Date: Mon, 02 May 2016 15:59:35 +0200
Subject: [Babel-users] Babel in Bird
In-Reply-To: <20160502133818.D6AF6FCCF@mail.crfreenet.org> (Ondrej Zajicek's
 message of "Mon, 2 May 2016 15:38:18 +0200")
References: <20160502133818.D6AF6FCCF@mail.crfreenet.org>
Message-ID: <87h9egr260.fsf@toke.dk>

Ondrej Zajicek <santiago at crfreenet.org> writes:

> I have two questions w.r.t. this sequence of events:
>
> 1) How is router restart and seqnos supposed to be handled without
> waiting for route timeout?

This is indeed a problem. Babeld sends a wildcard retraction before
shutting down (which I just taught Bird to handle; will send off the
patch tonight after testing it properly). I can add in sending such
retractions when an interface goes away as well.

But this problem can still occur on a crash, or if the retraction was
lost for whatever reason. In that case, waiting for things to expire is
the only option.

> 2) If a route is selected, then becomes unreachable/retracted, and
> there is no other route to be selected, is it still considered
> selected? I would say that no as the selection process (3.6) forbids
> retracted routes to be selected, but the BIRD implementation keeps the
> old selected route (now unreachable) in this case.

It is kept for a while (and installed as unreachable) to avoid transient
routing loops. This is described in section 2.8 of the RFC.

-Toke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20160502/b329c157/attachment.sig>

From santiago at crfreenet.org  Mon May  2 14:32:36 2016
From: santiago at crfreenet.org (Ondrej Zajicek)
Date: Mon, 2 May 2016 16:32:36 +0200
Subject: [Babel-users] Babel in Bird
In-Reply-To: <87h9egr260.fsf@toke.dk>
References: <20160502133818.D6AF6FCCF@mail.crfreenet.org>
 <87h9egr260.fsf@toke.dk>
Message-ID: <20160502143237.167D6FCCF@mail.crfreenet.org>

On Mon, May 02, 2016 at 03:59:35PM +0200, Toke H?iland-J?rgensen wrote:
> Ondrej Zajicek <santiago at crfreenet.org> writes:
> 
> > I have two questions w.r.t. this sequence of events:
> >
> > 1) How is router restart and seqnos supposed to be handled without
> > waiting for route timeout?
> 
> This is indeed a problem. Babeld sends a wildcard retraction before
> shutting down (which I just taught Bird to handle; will send off the
> patch tonight after testing it properly). I can add in sending such
> retractions when an interface goes away as well.
> 
> But this problem can still occur on a crash, or if the retraction was
> lost for whatever reason. In that case, waiting for things to expire is
> the only option.

Perhaps sending wildcard retraction not only in the last packet, but also
in the first one?


> > 2) If a route is selected, then becomes unreachable/retracted, and
> > there is no other route to be selected, is it still considered
> > selected? I would say that no as the selection process (3.6) forbids
> > retracted routes to be selected, but the BIRD implementation keeps the
> > old selected route (now unreachable) in this case.
> 
> It is kept for a while (and installed as unreachable) to avoid transient
> routing loops. This is described in section 2.8 of the RFC.

Well, section 2.8 (and in more detail section 3.5.5) specifies that we
should keep unreachable entries, but IMHO it does not specify that the
old route is considered selected/installed for a purpose of conditions in
section 3.5.4. The unreachable entry after retraction could be undestood
as a special case, unrelated to any route.


-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20160502/d005aa8c/attachment.sig>

From toke at toke.dk  Mon May  2 14:49:20 2016
From: toke at toke.dk (=?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?=)
Date: Mon, 02 May 2016 16:49:20 +0200
Subject: [Babel-users] Babel in Bird
In-Reply-To: <20160502143237.167D6FCCF@mail.crfreenet.org> (Ondrej Zajicek's
 message of "Mon, 2 May 2016 16:32:36 +0200")
References: <20160502133818.D6AF6FCCF@mail.crfreenet.org>
 <87h9egr260.fsf@toke.dk> <20160502143237.167D6FCCF@mail.crfreenet.org>
Message-ID: <87d1p4qzv3.fsf@toke.dk>

Ondrej Zajicek <santiago at crfreenet.org> writes:

> Perhaps sending wildcard retraction not only in the last packet, but also
> in the first one?

Don't see why not (and I think babeld does the same, actually).
Currently we are doing this when an iface comes up:

  babel_send_hello(ifa, 0);
  babel_send_wildcard_request(ifa);
  babel_send_update(ifa, 0);	/* Full update */

Guess sticking a wildcard retraction in after the hello wouldn't hurt.

>> > 2) If a route is selected, then becomes unreachable/retracted, and
>> > there is no other route to be selected, is it still considered
>> > selected? I would say that no as the selection process (3.6) forbids
>> > retracted routes to be selected, but the BIRD implementation keeps the
>> > old selected route (now unreachable) in this case.
>> 
>> It is kept for a while (and installed as unreachable) to avoid transient
>> routing loops. This is described in section 2.8 of the RFC.
>
> Well, section 2.8 (and in more detail section 3.5.5) specifies that we
> should keep unreachable entries, but IMHO it does not specify that the
> old route is considered selected/installed for a purpose of conditions
> in section 3.5.4. The unreachable entry after retraction could be
> undestood as a special case, unrelated to any route.

Hmm, you mean babel_select_route() should clear selected_in after
announcing the unreachable route to the core? Yes, that would appear to
be needed for the retraction to have any effect if the same router comes
back up before the entries are garbage collected...

-Toke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20160502/9520adcb/attachment.sig>

From jch at pps.univ-paris-diderot.fr  Thu May  5 13:02:55 2016
From: jch at pps.univ-paris-diderot.fr (Juliusz Chroboczek)
Date: Thu, 05 May 2016 15:02:55 +0200
Subject: [Babel-users] Babel in Bird
In-Reply-To: <20160502133818.D6AF6FCCF@mail.crfreenet.org>
References: <20160502133818.D6AF6FCCF@mail.crfreenet.org>
Message-ID: <87k2j8mzcw.wl-jch@pps.univ-paris-diderot.fr>

What you describe is perfectly correct.

> I have two questions w.r.t. this sequence of events:

> 1) How is router restart and seqnos supposed to be handled without
> waiting for route timeout?

It's worse than that, actually -- it's not the route timeout, it's the
source GC time.

The issue is a consequence of having a stateful loop-avoidance algorithm:
if the state is lost, the loop-avoidance algorithm gets confused, and only
recovers after the state has expired.

Babeld currently has two workarounds:

  - it stores the current seqno on disk when it shuts down, so that it can
    use the same seqno when it restarts;
  - it can optionally draw a random router-id at startup, so that the old
    and new states don't interfere.

It would be great to design a procedure to recover from this case without
a timeout, but I haven't given it much thought yet.  So for now consider
it as a flaw in the protocol.

-- Juliusz


From jch at pps.univ-paris-diderot.fr  Thu May  5 13:04:21 2016
From: jch at pps.univ-paris-diderot.fr (Juliusz Chroboczek)
Date: Thu, 05 May 2016 15:04:21 +0200
Subject: [Babel-users] Babel in Bird
In-Reply-To: <20160502143237.167D6FCCF@mail.crfreenet.org>
References: <20160502133818.D6AF6FCCF@mail.crfreenet.org>
 <87h9egr260.fsf@toke.dk>
 <20160502143237.167D6FCCF@mail.crfreenet.org>
Message-ID: <87inysmzai.wl-jch@pps.univ-paris-diderot.fr>

> Well, section 2.8 (and in more detail section 3.5.5) specifies that we
> should keep unreachable entries, but IMHO it does not specify that the
> old route is considered selected/installed for a purpose of conditions in
> section 3.5.4. The unreachable entry after retraction could be undestood
> as a special case, unrelated to any route.

Why does it matter?  Isn't the behaviour the same with both interpretations?

-- Juliusz


From santiago at crfreenet.org  Wed May 11 10:57:22 2016
From: santiago at crfreenet.org (Ondrej Zajicek)
Date: Wed, 11 May 2016 12:57:22 +0200
Subject: [Babel-users] Babel in Bird
In-Reply-To: <87inysmzai.wl-jch@pps.univ-paris-diderot.fr>
References: <20160502133818.D6AF6FCCF@mail.crfreenet.org>
 <87h9egr260.fsf@toke.dk>
 <20160502143237.167D6FCCF@mail.crfreenet.org>
 <87inysmzai.wl-jch@pps.univ-paris-diderot.fr>
Message-ID: <20160511105723.5AC0BFD1E@mail.crfreenet.org>

On Thu, May 05, 2016 at 03:04:21PM +0200, Juliusz Chroboczek wrote:
> > Well, section 2.8 (and in more detail section 3.5.5) specifies that we
> > should keep unreachable entries, but IMHO it does not specify that the
> > old route is considered selected/installed for a purpose of conditions in
> > section 3.5.4. The unreachable entry after retraction could be undestood
> > as a special case, unrelated to any route.
> 
> Why does it matter?  Isn't the behaviour the same with both interpretations?

You are right, in this case the difference does not matter. (I was confused
by mixing the route timeout with the source timeout).

BTW, why Babel accepts unfeasible updates of non-selected routes? It will
not cause problems as such route cannot be selected later (due to its
unfeasibility) but it seems strange.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."


From santiago at crfreenet.org  Wed May 11 11:08:36 2016
From: santiago at crfreenet.org (Ondrej Zajicek)
Date: Wed, 11 May 2016 13:08:36 +0200
Subject: [Babel-users] Babel in Bird
In-Reply-To: <87k2j8mzcw.wl-jch@pps.univ-paris-diderot.fr>
References: <20160502133818.D6AF6FCCF@mail.crfreenet.org>
 <87k2j8mzcw.wl-jch@pps.univ-paris-diderot.fr>
Message-ID: <20160511110836.27B3B1011A@mail.crfreenet.org>

On Thu, May 05, 2016 at 03:02:55PM +0200, Juliusz Chroboczek wrote:
> What you describe is perfectly correct.
> 
> > I have two questions w.r.t. this sequence of events:
> 
> > 1) How is router restart and seqnos supposed to be handled without
> > waiting for route timeout?
> 
> It's worse than that, actually -- it's not the route timeout, it's the
> source GC time.

Yes, you are right, i missed this.


> The issue is a consequence of having a stateful loop-avoidance algorithm:
> if the state is lost, the loop-avoidance algorithm gets confused, and only
> recovers after the state has expired.
> 
> Babeld currently has two workarounds:
> 
>   - it stores the current seqno on disk when it shuts down, so that it can
>     use the same seqno when it restarts;
>   - it can optionally draw a random router-id at startup, so that the old
>     and new states don't interfere.
> 
> It would be great to design a procedure to recover from this case without
> a timeout, but I haven't given it much thought yet.  So for now consider
> it as a flaw in the protocol.

Using random router-id seems like a good idea. Perhaps even an TLV that
describes 'nominal' configured router-id, so regular router-id could be
random, but routes could still contain configured router-id for admin
purposes. Unfortunately, Babel does not have support for something
like Opaque-LSA.

Could not help with this issue just to allow increasing seqnum by more
than 1 in reaction to recevied seqno request (3.8.1.2), to value
rcv_seqno+1 ?

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."


From jch at pps.univ-paris-diderot.fr  Wed May 11 13:48:19 2016
From: jch at pps.univ-paris-diderot.fr (Juliusz Chroboczek)
Date: Wed, 11 May 2016 15:48:19 +0200
Subject: [Babel-users] Babel in Bird
In-Reply-To: <20160511105723.5AC0BFD1E@mail.crfreenet.org>
References: <20160502133818.D6AF6FCCF@mail.crfreenet.org>
 <87h9egr260.fsf@toke.dk>
 <20160502143237.167D6FCCF@mail.crfreenet.org>
 <87inysmzai.wl-jch@pps.univ-paris-diderot.fr>
 <20160511105723.5AC0BFD1E@mail.crfreenet.org>
Message-ID: <8760ukiu3g.wl-jch@pps.univ-paris-diderot.fr>

> BTW, why Babel accepts unfeasible updates of non-selected routes? It will
> not cause problems as such route cannot be selected later (due to its
> unfeasibility) but it seems strange.

Yeah, very good question.  It's counterintuitive for me too, but it turns
out to work better that way:

1. Having an unfeasible route available makes it possible to use it for
   fallback after a single seqno increase.  If the route were not in your
   routing table at all, you'd need to acquire it after your selected
   route disappears, which may take some time, and will require even more
   time for things like link quality and hysteresis to converge.

2. Having an unfeasible route available makes it available for sending
   unicast requests (Section 3.8.1.2, fourth paragraph).

3. If the metric is non-isotonic, the best route might actually be
   unfeasible (in which case you'll need to send a request to select it,
   but everything will work out in the end).  Yeah, non-isotonic metrics
   are strange, but they do exist in nature.

-- Juliusz


From jch at pps.univ-paris-diderot.fr  Wed May 11 13:53:06 2016
From: jch at pps.univ-paris-diderot.fr (Juliusz Chroboczek)
Date: Wed, 11 May 2016 15:53:06 +0200
Subject: [Babel-users] Babel in Bird
In-Reply-To: <20160511110836.27B3B1011A@mail.crfreenet.org>
References: <20160502133818.D6AF6FCCF@mail.crfreenet.org>
 <87k2j8mzcw.wl-jch@pps.univ-paris-diderot.fr>
 <20160511110836.27B3B1011A@mail.crfreenet.org>
Message-ID: <874ma4itvh.wl-jch@pps.univ-paris-diderot.fr>

> Using random router-id seems like a good idea. Perhaps even an TLV that
> describes 'nominal' configured router-id, so regular router-id could be
> random, but routes could still contain configured router-id for admin
> purposes.  Unfortunately, Babel does not have support for something like
> Opaque-LSA.

Right on all counts.

> Could not help with this issue just to allow increasing seqnum by more
> than 1 in reaction to recevied seqno request (3.8.1.2), to value
> rcv_seqno+1 ?

I'm not sure it doesn't break loop avoidance, I'd need to think it over.

-- Juliusz


From dave.taht at gmail.com  Wed May 11 23:53:52 2016
From: dave.taht at gmail.com (Dave Taht)
Date: Wed, 11 May 2016 16:53:52 -0700
Subject: [Babel-users] osx, source specific routing, and babel
Message-ID: <CAA93jw62yCRjLN=ehNC9u7mXW__WNm8vX+6xB9gP1xF_Up9V3g@mail.gmail.com>

I booted up 1.8-git today on an osx box.

The log spews tons of

add rule: Function not implemented

messages.

and kernel_route(ADD): Function not implemented

And it can't figure out the wifi channel either.

I take it osx's policy routing stuff is way different? :(

...

Anyway, I am gearing up for a major test run this weekend, I think I
have a bit of a grip on the route flap weirdnesses I had last time,
and haven't crashed babel recently.....

-- 
Dave T?ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org


From dave.taht at gmail.com  Thu May 12 00:28:30 2016
From: dave.taht at gmail.com (Dave Taht)
Date: Wed, 11 May 2016 17:28:30 -0700
Subject: [Babel-users] perverse powersave bug with sta/ap mode
In-Reply-To: <CAA93jw4v2J4yuNX8xeYwD5JGaeH3L_zYwZELrgNdZBtBco6WJQ@mail.gmail.com>
References: <CAA93jw4v2J4yuNX8xeYwD5JGaeH3L_zYwZELrgNdZBtBco6WJQ@mail.gmail.com>
Message-ID: <CAA93jw7sFjLYP+9M-kj3gSHb4rQt9uM_+qvPdJ25xBTvwMgZaA@mail.gmail.com>

I am going to try this again this weekend. I'd written up some of the
contents of the thread
here:http://blog.cerowrt.org/post/failing_over_faster

And I just posted the follow-on test using the "chip" - which garnered
a bit more detail as to how the routes flapped:
http://blog.cerowrt.org/post/babel_half_fail/

Any ideas for what variables to better track appreciated.


From boutier at pps.univ-paris-diderot.fr  Thu May 12 11:13:37 2016
From: boutier at pps.univ-paris-diderot.fr (Matthieu Boutier)
Date: Thu, 12 May 2016 13:13:37 +0200
Subject: [Babel-users] osx, source specific routing, and babel
In-Reply-To: <CAA93jw62yCRjLN=ehNC9u7mXW__WNm8vX+6xB9gP1xF_Up9V3g@mail.gmail.com>
References: <CAA93jw62yCRjLN=ehNC9u7mXW__WNm8vX+6xB9gP1xF_Up9V3g@mail.gmail.com>
Message-ID: <013D13D7-3AD4-4D1A-A041-46F14C3663FD@pps.univ-paris-diderot.fr>

> add rule: Function not implemented
> and kernel_route(ADD): Function not implemented

That's true.  Did you know if there is any support for source-specific routing?  I read before that FreeBSD supports multiple tables... but also that the number of these tables must be set at compilation time.

> And it can't figure out the wifi channel either.

That may be doable.  It seems that this ObjC API could be used (not on iOS).

	https://developer.apple.com/library/mac/documentation/Networking/Reference/CoreWLANFrameworkRef

Matthieu



From santiago at crfreenet.org  Thu May 12 11:30:12 2016
From: santiago at crfreenet.org (Ondrej Zajicek)
Date: Thu, 12 May 2016 13:30:12 +0200
Subject: [Babel-users] Babel in Bird
In-Reply-To: <8760ukiu3g.wl-jch@pps.univ-paris-diderot.fr>
References: <20160502133818.D6AF6FCCF@mail.crfreenet.org>
 <87h9egr260.fsf@toke.dk>
 <20160502143237.167D6FCCF@mail.crfreenet.org>
 <87inysmzai.wl-jch@pps.univ-paris-diderot.fr>
 <20160511105723.5AC0BFD1E@mail.crfreenet.org>
 <8760ukiu3g.wl-jch@pps.univ-paris-diderot.fr>
Message-ID: <20160512113012.CCB58FD01@mail.crfreenet.org>

On Wed, May 11, 2016 at 03:48:19PM +0200, Juliusz Chroboczek wrote:
> > BTW, why Babel accepts unfeasible updates of non-selected routes? It will
> > not cause problems as such route cannot be selected later (due to its
> > unfeasibility) but it seems strange.
> 
> Yeah, very good question.  It's counterintuitive for me too, but it turns
> out to work better that way:
> 
> 1. Having an unfeasible route available makes it possible to use it for
>    fallback after a single seqno increase.  If the route were not in your
>    routing table at all, you'd need to acquire it after your selected
>    route disappears, which may take some time, and will require even more
>    time for things like link quality and hysteresis to converge.
> ...

Thanks, that makes sense.

But now i wonder why not to accept unfeasible updates of selected routes?
(At least in a case where router ids differ and the the update is handled
as retraction.) Obviously, that would case the route to be de-selected.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."


From zoobab at gmail.com  Thu May 12 15:00:18 2016
From: zoobab at gmail.com (Benjamin Henrion)
Date: Thu, 12 May 2016 17:00:18 +0200
Subject: [Babel-users] WBM9.1 babel tests?
Message-ID: <CANjd3ndbD1Wuo0xpbDuARvP=a0ZHYrQQ69vHxk-eEkTo1R37QA@mail.gmail.com>

Hi,

The routers used at WBMv9 in Porto are not reinstalled at UPC in
Barcelona with a remote wibed so that test cases can be launched:

http://ml.ninux.org/pipermail/battlemesh/2016-May/005032.html

If you login, there are many Batman and BMX test cases (they seem to
be TGZ's), but I have no idea what they should contain to run a
proprer Babel test case.

I would be really interested to see the channel switching which should
happen with the dirversity -z3 option.

If someone has some time to dig into it...

--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."


From jch at pps.univ-paris-diderot.fr  Thu May 12 15:10:41 2016
From: jch at pps.univ-paris-diderot.fr (Juliusz Chroboczek)
Date: Thu, 12 May 2016 17:10:41 +0200
Subject: [Babel-users] Babel in Bird
In-Reply-To: <20160512113012.CCB58FD01@mail.crfreenet.org>
References: <20160502133818.D6AF6FCCF@mail.crfreenet.org>
 <87h9egr260.fsf@toke.dk>
 <20160502143237.167D6FCCF@mail.crfreenet.org>
 <87inysmzai.wl-jch@pps.univ-paris-diderot.fr>
 <20160511105723.5AC0BFD1E@mail.crfreenet.org>
 <8760ukiu3g.wl-jch@pps.univ-paris-diderot.fr>
 <20160512113012.CCB58FD01@mail.crfreenet.org>
Message-ID: <7ioa8bcnwu.wl-jch@pps.univ-paris-diderot.fr>

> But now i wonder why not to accept unfeasible updates of selected routes?
> (At least in a case where router ids differ and the the update is handled
> as retraction.) Obviously, that would case the route to be de-selected.

I think you're right, that's a possible improvement.

-- Juliusz


From jehan.tremback at gmail.com  Mon May 16 21:28:37 2016
From: jehan.tremback at gmail.com (Jehan Tremback)
Date: Mon, 16 May 2016 14:28:37 -0700
Subject: [Babel-users] Verify ETX route metric
Message-ID: <CABG_PfQ7RykChOVbV417H2otbz08Fo6msS6DjWYqMLVyh7mXBA@mail.gmail.com>

This is more a theoretical than practical question right now, but is it
possible for a node to verify the ETX metrics of its neighbors? That is,
compute the ETX between myself and a given destination, and use it to
confirm that the additive ETX metric to that destination computed by the
neighbor is correct. I'm intending this to be used in a network which
involves bandwidth payments, to catch cheaters.

-Jehan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20160516/0e4d9854/attachment.html>

From jch at pps.univ-paris-diderot.fr  Sat May 21 16:33:25 2016
From: jch at pps.univ-paris-diderot.fr (Juliusz Chroboczek)
Date: Sat, 21 May 2016 18:33:25 +0200
Subject: [Babel-users] Possible changes to the Babel protocol
Message-ID: <87a8jjfk16.wl-jch@pps.univ-paris-diderot.fr>

Dear all,

Since the creation of a WG is out of our hands right now, I'd like to
start a discussion about whether we want to make an incompatible revision.

I'm sending this mail to both lists, please follow-up to babel at ietf.
I suggest that people express their opinions as followups to this mail,
after the discussion has settled I'll summarise and make this into a wiki
page.

We can adopt one of three approaches.  One would be to make an entirely
compatible revision -- tighten the spec, make the extension mechanism
a MUST, etc.

We could make a revision that is technically incompatible, but retain
version number 2 and design it so that it is possible to implement both
RFC 6126 and IETF Babel at the same time.  This would allow us to make
some TLV types optional (deprecate them) or to mark them as reserved.

The third approach is to make a new, Babel revision 3, which preserves the
spirit of Babel to the extent possible but is not compatible with Babel.
Unless the semantics are too different, it should be possible to implement
both Babel 2 and 3 in a single process with loop avoidance across the two
protocols, but at the cost of doubling the amount of control traffic.

I hold no opinion at the present time which approach is preferable.  I'm
just listing the changes that we could envision.  Notes of the form
[jch:...] indicate my current opinion on each change.  Whenever possible,
the name of the person who originally suggested the change is indicated in
brackets.


* Incompatible changes

Expand the primary metric to 32 bits (Tony) [jch: don't care, we can
carry a 32-bit metric in an extension TLV, but expanding the primary
metric is simpler]

Expand the TLV size to 16 bits (Tony) [jch: opposed, 8 bits is plenty
since TLVs must fit within a worst-case MTU]

Expand the TLV/sub-TLV space to 16 bits [jch: opposed, there's already
a mechanism for expansion of the TLV/sub-TLV space in RFC 7557]

Add a mandatory bit to TLVs (Tony) [jch: unsure]

Add a mandatory bit to sub-TLVs (Tony) [jch: in favour, they would
simplify the source-specific encoding quite a bit]

Clean up the encoding (Joel, Markus) [jch: mildly in favour, but afraid of
bikeshedding]


* Semi-compatible changes

Remove AE 0 and wildcard requests/retractions/IHU (Toke) [jch: in favour,
wildcard requests and retractions are confusing and not useful, wildcard
IHU can be encoded in a more parsimonious manner]

Remove plain (non-seqno) requests (jch) [jch: in favour, they complicate
the protocol and are not very useful, can be added as an extension if
needed]


* Compatible changes

Reserve router-ids all-zero and all-ones (Toke).  [jch: in favour]

Change the treatment of unfeasible updates from the selected neighbour,
(Section 3.5.4 of RFC 6126, Ondrej) [jch: not sure]

Change the SHOULD send a request when receiving an unfeasible update to
MUST (Section 3.8.2.2, Tony) [jch: in favour]

Rework the algorithm for sending requests when starving (Section 3.8.2.1,
jch).  [jch: in favour, but requires some experimental work]

-- Juliusz


From jch at pps.univ-paris-diderot.fr  Mon May 23 06:16:53 2016
From: jch at pps.univ-paris-diderot.fr (Juliusz Chroboczek)
Date: Mon, 23 May 2016 08:16:53 +0200
Subject: [Babel-users] Verify ETX route metric
In-Reply-To: <CABG_PfQ7RykChOVbV417H2otbz08Fo6msS6DjWYqMLVyh7mXBA@mail.gmail.com>
References: <CABG_PfQ7RykChOVbV417H2otbz08Fo6msS6DjWYqMLVyh7mXBA@mail.gmail.com>
Message-ID: <8760u52t9m.wl-jch@pps.univ-paris-diderot.fr>

> This is more a theoretical than practical question right now, but is it
> possible for a node to verify the ETX metrics of its neighbors? That is,
> compute the ETX between myself and a given destination, and use it to confirm
> that the additive ETX metric to that destination computed by the neighbor is
> correct.

Could you please explain?  I'm not sure I'm following you.

-- Juliusz



From jehan.tremback at gmail.com  Tue May 24 02:28:29 2016
From: jehan.tremback at gmail.com (Jehan Tremback)
Date: Mon, 23 May 2016 19:28:29 -0700
Subject: [Babel-users] Verify ETX route metric
In-Reply-To: <8760u52t9m.wl-jch@pps.univ-paris-diderot.fr>
References: <CABG_PfQ7RykChOVbV417H2otbz08Fo6msS6DjWYqMLVyh7mXBA@mail.gmail.com>
 <8760u52t9m.wl-jch@pps.univ-paris-diderot.fr>
Message-ID: <CABG_PfSkdGXEwf7+iFu43nHtbn-XtrdV_du_a+G3HUrrH33iKA@mail.gmail.com>

We are trying to mitigate one of the issues described in RFC6126:

> As defined in this document, Babel is a completely insecure protocol. Any
attacker can attract data traffic by advertising routes with a low metric.

We're concerned about this mostly because a node could advertise a low
metric, attract traffic, and then charge for it. One avenue we've thought
about is to run the link cost calculation end to end across the entire
route to a given destination. This could give a "second opinion" of what
the metric to that destination should be. This could be used as a way to
detect nodes that are cheating.

For example:

if

(A)--2--(B)--3--(C)--1--(D) = 5

then

(A)----------5----------(D) = 5

A performs the link cost calculation between herself and D to find out if B
or C are cheating. Have you thought about this at all? What's your opinion?

-Jehan

On Sun, May 22, 2016 at 11:16 PM, Juliusz Chroboczek <
jch at pps.univ-paris-diderot.fr> wrote:

> > This is more a theoretical than practical question right now, but is it
> > possible for a node to verify the ETX metrics of its neighbors? That is,
> > compute the ETX between myself and a given destination, and use it to
> confirm
> > that the additive ETX metric to that destination computed by the
> neighbor is
> > correct.
>
> Could you please explain?  I'm not sure I'm following you.
>
> -- Juliusz
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20160523/bef9d19a/attachment.html>

From jehan.tremback at gmail.com  Tue May 24 04:46:07 2016
From: jehan.tremback at gmail.com (Jehan Tremback)
Date: Mon, 23 May 2016 21:46:07 -0700
Subject: [Babel-users] Verify ETX route metric
In-Reply-To: <CABG_PfSkdGXEwf7+iFu43nHtbn-XtrdV_du_a+G3HUrrH33iKA@mail.gmail.com>
References: <CABG_PfQ7RykChOVbV417H2otbz08Fo6msS6DjWYqMLVyh7mXBA@mail.gmail.com>
 <8760u52t9m.wl-jch@pps.univ-paris-diderot.fr>
 <CABG_PfSkdGXEwf7+iFu43nHtbn-XtrdV_du_a+G3HUrrH33iKA@mail.gmail.com>
Message-ID: <CABG_PfRJ7hAS6OA-bEZ7JXYQaTgOE=3VFR-iUiBQOs6Lx6CO-w@mail.gmail.com>

Sorry, the diagram should be:

(A)--2--(B)--3--(C)--1--(D) = 6

(A)----------5----------(D) = 6

On Mon, May 23, 2016 at 7:28 PM, Jehan Tremback <jehan.tremback at gmail.com>
wrote:

> We are trying to mitigate one of the issues described in RFC6126:
>
> > As defined in this document, Babel is a completely insecure protocol. Any
> attacker can attract data traffic by advertising routes with a low metric.
>
> We're concerned about this mostly because a node could advertise a low
> metric, attract traffic, and then charge for it. One avenue we've thought
> about is to run the link cost calculation end to end across the entire
> route to a given destination. This could give a "second opinion" of what
> the metric to that destination should be. This could be used as a way to
> detect nodes that are cheating.
>
> For example:
>
> if
>
> (A)--2--(B)--3--(C)--1--(D) = 5
>
> then
>
> (A)----------5----------(D) = 5
>
> A performs the link cost calculation between herself and D to find out if
> B or C are cheating. Have you thought about this at all? What's your
> opinion?
>
> -Jehan
>
> On Sun, May 22, 2016 at 11:16 PM, Juliusz Chroboczek <
> jch at pps.univ-paris-diderot.fr> wrote:
>
>> > This is more a theoretical than practical question right now, but is it
>> > possible for a node to verify the ETX metrics of its neighbors? That is,
>> > compute the ETX between myself and a given destination, and use it to
>> confirm
>> > that the additive ETX metric to that destination computed by the
>> neighbor is
>> > correct.
>>
>> Could you please explain?  I'm not sure I'm following you.
>>
>> -- Juliusz
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20160523/c83cd84d/attachment.html>

From jch at pps.univ-paris-diderot.fr  Tue May 24 16:04:28 2016
From: jch at pps.univ-paris-diderot.fr (Juliusz Chroboczek)
Date: Tue, 24 May 2016 18:04:28 +0200
Subject: [Babel-users] Verify ETX route metric
In-Reply-To: <CABG_PfSkdGXEwf7+iFu43nHtbn-XtrdV_du_a+G3HUrrH33iKA@mail.gmail.com>
References: <CABG_PfQ7RykChOVbV417H2otbz08Fo6msS6DjWYqMLVyh7mXBA@mail.gmail.com>
 <8760u52t9m.wl-jch@pps.univ-paris-diderot.fr>
 <CABG_PfSkdGXEwf7+iFu43nHtbn-XtrdV_du_a+G3HUrrH33iKA@mail.gmail.com>
Message-ID: <874m9ne92r.wl-jch@pps.univ-paris-diderot.fr>

> We're concerned about this mostly because a node could advertise a low metric,
> attract traffic, and then charge for it. One avenue we've thought about is to
> run the link cost calculation end to end across the entire route to a given
> destination. This could give a "second opinion" of what the metric to that
> destination should be. This could be used as a way to detect nodes that are
> cheating.

Interesting idea.  No, I have no idea how this could be done.

-- Juliusz


From hrogge at gmail.com  Tue May 24 17:11:45 2016
From: hrogge at gmail.com (Henning Rogge)
Date: Tue, 24 May 2016 19:11:45 +0200
Subject: [Babel-users] Verify ETX route metric
In-Reply-To: <CABG_PfSkdGXEwf7+iFu43nHtbn-XtrdV_du_a+G3HUrrH33iKA@mail.gmail.com>
References: <CABG_PfQ7RykChOVbV417H2otbz08Fo6msS6DjWYqMLVyh7mXBA@mail.gmail.com>
 <8760u52t9m.wl-jch@pps.univ-paris-diderot.fr>
 <CABG_PfSkdGXEwf7+iFu43nHtbn-XtrdV_du_a+G3HUrrH33iKA@mail.gmail.com>
Message-ID: <CAGnRvuqPMETA_3jBg70GB6d4tvXUVGSwDXxZc187iYpf_R9i3Q@mail.gmail.com>

Hi,

there are some ideas that third nodes who can overhear a link between
two other nodes can do some checking, but it is difficult to do and
only gives you a probabilistic chance to detect someone fooling
someone else.

Of course defending against this kind of "insider attacker" is
practically impossible unless you have a node-id based cryptographic
signature... otherwise the attacker can just spoof his identity.

Henning Rogge

On Tue, May 24, 2016 at 4:28 AM, Jehan Tremback
<jehan.tremback at gmail.com> wrote:
> We are trying to mitigate one of the issues described in RFC6126:
>
>> As defined in this document, Babel is a completely insecure protocol. Any
>> attacker can attract data traffic by advertising routes with a low metric.
>
> We're concerned about this mostly because a node could advertise a low
> metric, attract traffic, and then charge for it. One avenue we've thought
> about is to run the link cost calculation end to end across the entire route
> to a given destination. This could give a "second opinion" of what the
> metric to that destination should be. This could be used as a way to detect
> nodes that are cheating.
>
> For example:
>
> if
>
> (A)--2--(B)--3--(C)--1--(D) = 5
>
> then
>
> (A)----------5----------(D) = 5
>
> A performs the link cost calculation between herself and D to find out if B
> or C are cheating. Have you thought about this at all? What's your opinion?
>
> -Jehan
>
> On Sun, May 22, 2016 at 11:16 PM, Juliusz Chroboczek
> <jch at pps.univ-paris-diderot.fr> wrote:
>>
>> > This is more a theoretical than practical question right now, but is it
>> > possible for a node to verify the ETX metrics of its neighbors? That is,
>> > compute the ETX between myself and a given destination, and use it to
>> > confirm
>> > that the additive ETX metric to that destination computed by the
>> > neighbor is
>> > correct.
>>
>> Could you please explain?  I'm not sure I'm following you.
>>
>> -- Juliusz
>>
>
>
> _______________________________________________
> Babel-users mailing list
> Babel-users at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users


From mmitar at gmail.com  Sat May 28 16:26:16 2016
From: mmitar at gmail.com (Mitar)
Date: Sat, 28 May 2016 18:26:16 +0200
Subject: [Babel-users] Possible changes to the Babel protocol
In-Reply-To: <87a8jjfk16.wl-jch@pps.univ-paris-diderot.fr>
References: <87a8jjfk16.wl-jch@pps.univ-paris-diderot.fr>
Message-ID: <CAKLmikN7unLnPt7Bg9Cjfom-ec1bbMb=S-EVM=sh5u753bMCzQ@mail.gmail.com>

Hi!

I would be in favor of making an incompatible but improved version,
but against forking of current main codebase (and resources directed
in maintaining it). So in some way I would be that current main
codebase should also move to this new "major" version. I see it simply
from the open source project perspective as a new major (backwards
incompatible version). In addition, there should be a transition path
provided for networks with previous major version. For example, by
running both Babel versions in parallel (this might require using a
different port for a new version?).


Mitar

On Sat, May 21, 2016 at 6:33 PM, Juliusz Chroboczek
<jch at pps.univ-paris-diderot.fr> wrote:
> Dear all,
>
> Since the creation of a WG is out of our hands right now, I'd like to
> start a discussion about whether we want to make an incompatible revision.
>
> I'm sending this mail to both lists, please follow-up to babel at ietf.
> I suggest that people express their opinions as followups to this mail,
> after the discussion has settled I'll summarise and make this into a wiki
> page.
>
> We can adopt one of three approaches.  One would be to make an entirely
> compatible revision -- tighten the spec, make the extension mechanism
> a MUST, etc.
>
> We could make a revision that is technically incompatible, but retain
> version number 2 and design it so that it is possible to implement both
> RFC 6126 and IETF Babel at the same time.  This would allow us to make
> some TLV types optional (deprecate them) or to mark them as reserved.
>
> The third approach is to make a new, Babel revision 3, which preserves the
> spirit of Babel to the extent possible but is not compatible with Babel.
> Unless the semantics are too different, it should be possible to implement
> both Babel 2 and 3 in a single process with loop avoidance across the two
> protocols, but at the cost of doubling the amount of control traffic.
>
> I hold no opinion at the present time which approach is preferable.  I'm
> just listing the changes that we could envision.  Notes of the form
> [jch:...] indicate my current opinion on each change.  Whenever possible,
> the name of the person who originally suggested the change is indicated in
> brackets.
>
>
> * Incompatible changes
>
> Expand the primary metric to 32 bits (Tony) [jch: don't care, we can
> carry a 32-bit metric in an extension TLV, but expanding the primary
> metric is simpler]
>
> Expand the TLV size to 16 bits (Tony) [jch: opposed, 8 bits is plenty
> since TLVs must fit within a worst-case MTU]
>
> Expand the TLV/sub-TLV space to 16 bits [jch: opposed, there's already
> a mechanism for expansion of the TLV/sub-TLV space in RFC 7557]
>
> Add a mandatory bit to TLVs (Tony) [jch: unsure]
>
> Add a mandatory bit to sub-TLVs (Tony) [jch: in favour, they would
> simplify the source-specific encoding quite a bit]
>
> Clean up the encoding (Joel, Markus) [jch: mildly in favour, but afraid of
> bikeshedding]
>
>
> * Semi-compatible changes
>
> Remove AE 0 and wildcard requests/retractions/IHU (Toke) [jch: in favour,
> wildcard requests and retractions are confusing and not useful, wildcard
> IHU can be encoded in a more parsimonious manner]
>
> Remove plain (non-seqno) requests (jch) [jch: in favour, they complicate
> the protocol and are not very useful, can be added as an extension if
> needed]
>
>
> * Compatible changes
>
> Reserve router-ids all-zero and all-ones (Toke).  [jch: in favour]
>
> Change the treatment of unfeasible updates from the selected neighbour,
> (Section 3.5.4 of RFC 6126, Ondrej) [jch: not sure]
>
> Change the SHOULD send a request when receiving an unfeasible update to
> MUST (Section 3.8.2.2, Tony) [jch: in favour]
>
> Rework the algorithm for sending requests when starving (Section 3.8.2.1,
> jch).  [jch: in favour, but requires some experimental work]
>
> -- Juliusz
>
> _______________________________________________
> Babel-users mailing list
> Babel-users at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users



-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m