You do not explain why we (or kernel) NEED(s) this.
It is not so important how SMALL it is
though it may cause problems how LARGE it is.

I had explained the reasons for having prefix list i/f in my previous mail. To recap :
-  User don't need to know what the definition of a prefix is, all he has to do is ask
    the kernel and get the list. Otherwise different user apps will have to know the
    definition of a prefix and parse the entry themselves. The parsing is non-trivial (eg
    the address should not LL or MC, there should be no nexthop and it should be added via
    an RA, etc).
-  The kernel code to get the prefix list is small, the top level inet6_dump_fib uses
    either the dump_node or the dump_prefix, the latter being the new user interface. Having
    a user interface makes it easier to get the prefix list without significant bloat to the
    kernel.

This is design issue; how we should provide L3 per-interface 
information to userspace; eg. in_device and/or inet6_dev things 
including per-interface statistics.

Since I think it is not appropriate to provide per-interface 
statistics via RTM_xxxROUTE, so I don't agree to provide 
the RA infomation (i.e. Manage/Otherconf Flags) via 
RTM_xxxROUTE.

Options:
 - use RTM_xxxLINK for L3 operation
 - introduce RTM_xxxIFACE for L3 per-interface operations

Yes, there are a couple of different ways to do this. One is as you have suggested, but there
is a problem with it. The existing RTM_GETLINK interface returns very generic elements of the
dev (mtu, hardware address, dev statistics), while the change you suggested is specific to
ipv6. I am not sure if this is a good design to implement. Either we could use the current
(submitted) way or use a different RTM_GETADDR interface in inet6_fill_ifaddr (and introduce
RTM_IFACEFLAGS). This will be specific to IPv6. Are you agreeable to this ?

Well, on moving forward; you can split your patch up to 3 things:
  1. fix routing flags
  2. provide Managed/Otherconf flags API
 (3. provide the prefix list API (if it IS required))

I'm not against the first item.
We need to discuss on the design related to the 2nd item.
I don't think that we really need 3rd item.

- I am ok with 1 :-)
- I have suggested changes for 2, please let me know what you think, whether we can go with the
   old way or make the change suggested above.
- I believe we need #3 for the reasons given above.

Thanks,

- KK