Re: [homenet] Alia Atlas' No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)
Heya, thanks for the review :) > -- > COMMENT: > -- > > I support Brian's Discuss. > > 1) In Sec 1.1, it states "...in homenet environments where multiple IPv6 > > source-prefixes can be present, routing based on source and > destination > address is necessary [RFC7368]." > > Looking at RFC7368, I don't see anything that matches the strength of > this > assertion which says in Sec 3.2.4 merely "Another avenue is to > introduce support > throughout the homenet for routing that is based on the source as > well as the destination address of each packet." > > While src-dest routing is certainly a solution - and an interesting > one - it doesn't > seem at all appropriate for an HNCP spec to assert that it is > necessary. True. However, we were asked to describe the applicability, and I consider e.g. tunneling solution inferior so I would rather not propose that here. (And you either need tunneling or src-dst routing for this to work, and defining new tunneling scheme just for this to work is much harder than saying src-dst). Without one of them, the solution will break BCP-38 and not work. What would be the other realistic option to change here? The whole applicability mess showed up somewhere in the review process, and I would rather not have it, but dropping it is not an option either. > 2) For the DNCP profile, draft-ietf-homenet-dncp-12 says "Anything > received over multicast, except Node Endpoint TLV (Section 7.2.1) and > Network State TLV (Section 7.2.2)." and this draft says "HNCP nodes MUST > ignore all Node State TLVs received via multicast > on a link which has DNCP security enabled in order to prevent spoofing > of node state changes." > Could you please align and clarify the desired behavior for HNCP? The part you are quoting from DNCP profile notes only what _can_ be defined to be ignored by profiles. HNCP as written is correct. I welcome deltas which make it more correct, but you did not quote the preceding paragraph which says this in DNCP: o When receiving TLVs, what sort of TLVs are ignored in addition - as specified in Section 4.4 - e.g., for security reasons. While the security of the node data published within the Node State TLVs is already ensured by the base specification (if secure unicast transport is enabled, Node State TLVs are sent only via unicast as multicast ones are ignored on receipt), if a profile adds TLVs that are sent outside the node data, a profile should indicate whether or not those TLVs should be ignored if they are received via multicast or non-secured unicast. A DNCP profile may define the following DNCP TLVs to be safely ignored: Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Alia Atlas' No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)
>> While src-dest routing is certainly a solution - and an interesting >> one - it doesn't seem at all appropriate for an HNCP spec to assert >> that it is necessary. > True. However, we were asked to describe the applicability, and > I consider e.g. tunneling solution inferior so I would rather not > propose that here. I was under the impression that there was consensus that tunnelling is a bad idea, and that source-specific routing is superior. I may be mis-reading Alia, but perhaps she means that some deployments might not require the added complexity of source-specific routing, and might be able to get away with ordinary next-hop routing. (Alia, apologies if I misunderstood.) Recall that our main concern is to ensure that Homenet routers from different vendors interoperate. Source-specific routing, when done right, interoperates with ordinary next-hop routing under the following conditions: (1) all edge routers are source-specific, (2) there is a connected backbone of source-specific routers, and (3) at least one of the routers in the backbone announces a non-specific default route. (1) and (3) are easy enough, but (2) is problematic: it is a global condition, one that can only be verified with global knowledge of the topology. So I agree with Markus -- while it might be possible to get away with a weaker requirement, it is way simpler to make source-specific routing a MUST. If there is market demand, we might want to write a different document that describes a weaker set of requirements for interior-only (non-gateway-capable) Homenet nodes. (A more desirable alternative, of course, would be to split the requirements in HNCP into HNCP requirements and Homenet requirements, but I gather that there's consensus that it's somewhat late to embark on such an ambitious project. I rather agree with that assessment -- we need to get Homenet out of the door quickly, lest people start deploying IPv6 NAT.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Alia Atlas' No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)
Alia Atlas has entered the following ballot position for draft-ietf-homenet-hncp-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/ -- COMMENT: -- I support Brian's Discuss. 1) In Sec 1.1, it states "...in homenet environments where multiple IPv6 source-prefixes can be present, routing based on source and destination address is necessary [RFC7368]." Looking at RFC7368, I don't see anything that matches the strength of this assertion which says in Sec 3.2.4 merely "Another avenue is to introduce support throughout the homenet for routing that is based on the source as well as the destination address of each packet." While src-dest routing is certainly a solution - and an interesting one - it doesn't seem at all appropriate for an HNCP spec to assert that it is necessary. 2) For the DNCP profile, draft-ietf-homenet-dncp-12 says "Anything received over multicast, except Node Endpoint TLV (Section 7.2.1) and Network State TLV (Section 7.2.2)." and this draft says "HNCP nodes MUST ignore all Node State TLVs received via multicast on a link which has DNCP security enabled in order to prevent spoofing of node state changes." Could you please align and clarify the desired behavior for HNCP? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
