I added hybrid category to manually configured border discovery interface types (MAY):
https://github.com/fingon/ietf-drafts/commit/0fb83030fd2c2b8d933417aaca2409a043320713 It is usable _within_ home, if (for example) CER is (legacy) RFC7084, and two HNCP routers are plugged to it. By default, they are unable to learn of each other (and do the HNCP services with each other such as prefix assignment, service discovery, and so on). IPv6 on them will probably require some manual configuration and-or RFC7084bis behavior on part of the CER. I’m not sure this is still a good idea, as there’d be duplicate prefixes retrieved from legacy router (if 7084bis), but at least it would enable HNCP router 1 -> HNCP router 2 clients to communicate on IP level, and to discover services. Another thing I'm wondering about is how to handle services that do _not_ need to have any explicit state. Should there be some sort of feature announcement(/support) mechanism? A concrete example: PCP or UPnP IGDv2 proxy on inner router needs to know _only_ about the CERs. It does not need to know anything more, and it can _try_ to use the protocol as-is (as almost mandated by PCP proxy discussions currently, I guess), but given extra information about support for the feature on the CER, the response to the host requesting services from a router that does not support it could be better. Instead of effectively blackholing packet for service that the CER does not support, proxy on the first-hop inner router could provide (possibly) more useful error response immediately. _Currently_ we implemented PCP proxying just blindly, hoping the CER does it, and otherwise not returning any error. As in case of multi-homing the error state would depend on the source address chosen by the client in any case, I'm not sure non-source-address-specific error messages would bring any extra value here anyway. For example, in case of PCP, returning (e.g.) NO_RESOURCES may not make client try different source address. Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
