Tested peer (quagga) doesn't interpret it nicely (i.e. it shuts the connection
down). Better not tell anything.
Signed-off-by: Benjamin Cama <benoar@dolka.fr>
We would advertise IPv6 routes to non-multiprotocol aware peers. Fix that.
Also, fix the way we parse options, to handle multiple optional parameters with
one capability in it (or many; it's just the way quagga send them).
Signed-off-by: Benjamin Cama <benoar@dolka.fr>
Add IPv6 routes advertisement handling, with MP path attributes heading
prepared on initialization.
BTW, fix a bug in attribute size calculation (for extended attr).
Signed-off-by: Benjamin Cama <benoar@dolka.fr>
We will need to do that when we will send IPv6 routes (RFC4760 says we SHOULD
NOT carry this attribute when we will send UPDATE without NLRI). So, we save
the length of all the attributes except NEXT_HOP for later memcpy().
Signed-off-by: Benjamin Cama <benoar@dolka.fr>
Optional Parameters is defined in RFC4271 and Capability advertisement in
RFC3392. For now, we only hande them upon receiving an OPEN message.
Signed-off-by: Benjamin Cama <benoar@dolka.fr>
