Hi Alex, Thanks for the pointers, will look into this further. Cheers, -- David > On 12 Nov 2017, at 01:09, Alexander Aring <aring@xxxxxxxxxxxx> wrote: > > Hi, > > On Sat, Nov 11, 2017 at 7:06 PM, Alexander Aring <aring@xxxxxxxxxxxx> wrote: >> Hi, >> >> On Sat, Nov 11, 2017 at 5:59 PM, David Palma <david.palma@xxxxxxx> wrote: >>> >>>> On 11 Nov 2017, at 19:53, Michael Richardson <mcr@xxxxxxxxxxxx> wrote: >>>> >>>> >>>> David Palma <david.palma@xxxxxxx> wrote: >>>>> I'm all for routing and starting with RPL is fine. However, the idea >>>>> was also to enable traffic differentiation based on flows (the SDN >>>>> part), without breaking them, and not only based on IP >>>>> addresses. That's why I mentioned that I used routing and ip6tables. >>>> >>>> I don't understand what the problem is. >>>> What would you do with bridged interfaces in an SDN? >>> >>> For example, if you use Open vSwitch for the SDN part, you add an interface to a bridge and manage flows from there. >>> >>>> What kind of breaking are you speaking of? >>> >>> By breaking I mean, for example: >>> - establish a CoAP transaction with DTLS through one interface/network (e.g. .11, fd03::120) >> >> Check out ndisc proxy for IPv6. >> >> There is no automatically handling for that inside the kernel (please >> send-patches, somebody wanted already such feature). What I mean for >> IPv4 yes, but for IPv6 you need a daemon like [0]. >> > > btw: we need short address handling for this... because 2 types of mac > addresses is not really supported by net core api and currently we > handle this _very_ 802.15.4 interface specific. Just you know about... > that you run into issues with that (When you not solve it). Patches > are welcome always! > > - Alex > -- > To unsubscribe from this list: send the line "unsubscribe linux-wpan" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
