[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] Q. should mdns be announcing an ip4 address of

From: Joel Cunningham
Subject: Re: [lwip-devel] Q. should mdns be announcing an ip4 address of
Date: Fri, 29 Dec 2017 10:17:11 -0600
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 12/29/2017 6:22 AM, Douglas wrote:

Working on the mdns responder, and noticed that it sends out ipv4
packets before the interface has an ipv4 address, so sends them out with
a source address of and announces an A record with address

This is when using dhcp to obtain the ipv4 address, so the interface can
be up and ipv6 can be operational and announced even before ipv4.

Every time the connection drops and reconnects it goes thought this
announcement. Given that UDP is not reliable, might this be mdns less

Would anyone know if this is the correct behaviour.
I've worked a lot with Apple's mDNSResponder and am familiar with RFC 6762, hopefully my background can provide some guidance :)

A. Should the mdns responder announce to an ipv4 broadcast address
before the interface has an ipv4 address? If not then it could still
announce to the ipv6 broadcast address before it has an ipv4 address.
I would say no because the responder is advertising services that can't be contacted by a remote host (due to the interface being down).

I can also think of other complications if multiple devices advertised conflicting service instances via a address and the network traffic happened to be loopedback (how would you know which packets were from which device?)

IPv4 and IPv6 are treated as ships passing in the night and you can even think of them as separate .local. domains instances. See https://tools.ietf.org/html/rfc6762#section-20.  So advertising on IPv6 when that link is up (but not IPv4) is completely fine.  Maybe the IPv4 link never comes up.

B. Should the mdns responder announce an A record of before it
has an ipv4 address? Might this flush out the address in case it
changes, or would it be better to just skip announcing this A record
until the address is obtained?
An A record with address is definitely not correct.  In terms of how to flush old cache entries in remote caches, there are a couple different active mechanisms depending on what's happening with the resource:

1) If the resource record is going away, i.e. service is removed or the host is shutting down, then a Goodbye packet should be sent with a TTL of 0, but all the same rdata.  See https://tools.ietf.org/html/rfc6762#section-10.1

2) In the case where a device's link goes down after advertising an A record with a previous address, when the link goes back up (with new address), the device will Probe and Announce the new record with the cache flush bit enabled, causing the remote caches to be updated. See https://tools.ietf.org/html/rfc6762#section-10.2 and https://tools.ietf.org/html/rfc6762#section-8


reply via email to

[Prev in Thread] Current Thread [Next in Thread]