[mdns] add support for legacy unicast response feature

[Cristib05]

This PR adds support for Legacy Unicast Response feature in mDNS module.

[size-report]

Size Report of OpenThread

Merging #10053 into main(330b175).

name	branch	text	data	bss	total
ot-cli-ftd	main	466640	856	66348	533844
	#10053	466640	856	66348	533844
	+/-	0	0	0	0
ot-ncp-ftd	main	435492	760	61560	497812
	#10053	435492	760	61560	497812
	+/-	0	0	0	0
libopenthread-ftd.a	main	235875	95	40294	276264
	#10053	235875	95	40294	276264
	+/-	0	0	0	0
libopenthread-cli-ftd.a	main	57533	0	8075	65608
	#10053	57533	0	8075	65608
	+/-	0	0	0	0
libopenthread-ncp-ftd.a	main	31863	0	5916	37779
	#10053	31863	0	5916	37779
	+/-	0	0	0	0
ot-cli-mtd	main	364400	760	51204	416364
	#10053	364400	760	51204	416364
	+/-	0	0	0	0
ot-ncp-mtd	main	346932	760	46432	394124
	#10053	346932	760	46432	394124
	+/-	0	0	0	0
libopenthread-mtd.a	main	157940	0	25166	183106
	#10053	157940	0	25166	183106
	+/-	0	0	0	0
libopenthread-cli-mtd.a	main	39756	0	8059	47815
	#10053	39756	0	8059	47815
	+/-	0	0	0	0
libopenthread-ncp-mtd.a	main	24743	0	5916	30659
	#10053	24743	0	5916	30659
	+/-	0	0	0	0
ot-cli-ftd-br	main	549952	864	131188	682004
	#10053	550304	864	131188	682356
	+/-	+352	0	0	+352
libopenthread-ftd-br.a	main	323860	100	105110	429070
	#10053	324168	100	105110	429378
	+/-	+308	0	0	+308
libopenthread-cli-ftd-br.a	main	71394	0	8099	79493
	#10053	71394	0	8099	79493
	+/-	0	0	0	0
ot-rcp	main	62248	564	20604	83416
	#10053	62248	564	20604	83416
	+/-	0	0	0	0
libopenthread-rcp.a	main	9542	0	5052	14594
	#10053	9542	0	5052	14594
	+/-	0	0	0	0
libopenthread-radio.a	main	19040	0	214	19254
	#10053	19040	0	214	19254
	+/-	0	0	0	0

[abtink]

Thanks @Cristib05 for implementing this. Looks good overall. Couple of suggestions below. Thanks.

Another point if we can add support for this in unit test? We can add a new test-cases TestLegacyUnicast?

[Cristib05]

Next step will be to add a unit test for this feature.

[abtink]

Looks great. Thanks @Cristib05

Some smaller suggestions below.

[jwhui]

Looks good overall. Commented on a couple minor nits.

[abtink]

@Cristib05, a thought occurred to me regarding enabling legacy unicast support and whether it could be used by devices outside the local link. I recalled that for "direct unicast", RFC 6762 section 5.5 mentions this:

Since it is possible for a unicast query to be received from a machine outside the local link, responders SHOULD check that the source address in the query packet matches the local subnet for that link (or, in the case of IPv6, the source address has an on-link prefix) and silently ignore the packet if not.

Although I don't think the same is explicitly mentioned for legacy unicast, I believe the same situation could arise. We might want to add some mechanism to address this.

Some potential solutions:

• We could limit legacy unicast support to IPv6 and only when the sender's address is link-local. This would be easy to implement directly within the mdns module in OT.
• If we want the same behavior for IPv4, we would need a platform API to check this. For instance, we could add an otPlatMdnsIsAddressLocal() API to pass the address to the platform for verification.

Thoughts?

[Cristib05]

@Cristib05, a thought occurred to me regarding enabling legacy unicast support and whether it could be used by devices outside the local link. I recalled that for "direct unicast", RFC 6762 section 5.5 mentions this:

Since it is possible for a unicast query to be received from a machine outside the local link, responders SHOULD check that the source address in the query packet matches the local subnet for that link (or, in the case of IPv6, the source address has an on-link prefix) and silently ignore the packet if not.

Although I don't think the same is explicitly mentioned for legacy unicast, I believe the same situation could arise. We might want to add some mechanism to address this.

Some potential solutions:

• We could limit legacy unicast support to IPv6 and only when the sender's address is link-local. This would be easy to implement directly within the mdns module in OT.
• If we want the same behavior for IPv4, we would need a platform API to check this. For instance, we could add an otPlatMdnsIsAddressLocal() API to pass the address to the platform for verification.

Thoughts?

Hi @abtink,
Regarding the Legacy Unicast Response feature, the answer for this type of query is sent unicast, but the query is sent using either ff02::fb:5353 or 224.0.0.251:5353 which implies that the query originates from a local network.
Not specifically for Direct Unicast feature, but I think we should add in another PR checks recommended in RFC6762, section 5.5 Direct Unicast Queries to Port 5353 and 11. Source Address Check, and corresponding unit tests.
If you think that's ok, I can start working on those features.

[abtink]

Thanks @Cristib05.

Hi @abtink,
Regarding the Legacy Unicast Response feature, the answer for this type of query is sent unicast, but the query is sent using either ff02::fb:5353 or 224.0.0.251:5353 which implies that the query originates from a local network.

Yes. I see. This makes sense.

Not specifically for Direct Unicast feature, but I think we should add in another PR checks recommended in RFC6762, section 5.5 Direct Unicast Queries to Port 5353 and 11. Source Address Check, and corresponding unit tests.
If you think that's ok, I can start working on those features.

Sounds good. Thanks.