[Unstrung-hackers] [[NET-NEXT]] Added dump function to recognise rpl extension header option(63)

Michael Richardson mcr at sandelman.ca
Thu May 4 13:04:50 EDT 2017


Stefan Schmidt <stefan at osg.samsung.com> wrote:
    > Michael, is there more that needs doing in the kernel? Some basic
    > sanity checking
    > of the packet maybe?

Yes, but this is enough to work around breakage for now.
Really, given rfc2460bis view on Hbh extensions, the kernel should ignore
them all unless it has been told to examine them.
I think that there should be a bit field (256 possible extensions)
which say which are critical.

    >> static const struct tlvtype_proc tlvprochopopt_lst[] = {
    >> {
    >> .type	= IPV6_TLV_ROUTERALERT,
    >> @@ -798,6 +807,10 @@ static const struct tlvtype_proc tlvprochopopt_lst[] =
    >> {
    >> .type	= IPV6_TLV_CALIPSO,
    >> .func	= ipv6_hop_calipso,
    >> },
    >> +	{
    >> +		.type	= IPV6_TLV_RPL,
    >> +		.func	= ipv6_hop_rpl,


    > Is the RPL option considered an hop-by-hop extension? I wonder about
    > the *_hop_*
    > naming here.

Yes.

There is a rank value which needs to go up/down depending whether the
packet is going towards or away from the root.   How did we agree to
handle this at netdev? I might have to watch the video to remember :-)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://lists.sandelman.ca/pipermail/unstrung-hackers/attachments/20170504/cffb2aa9/attachment.sig>


More information about the Unstrung-hackers mailing list