tasklwIP - A Lightweight TCP/IP stack - Tasks: task #14274, dns: do we need to separate IPv4...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #14274: dns: do we need to separate IPv4 servers from IPv6 servers?

Submitter:  Simon Goldschmidt <goldsimon>
Submitted:  Wed 14 Dec 2016 09:15:01 PM UTC
   
 
Category:  None Should Start On:  Wed 14 Dec 2016 12:00:00 AM UTC
Should be Finished on:  Wed 14 Dec 2016 12:00:00 AM UTC Priority:  5 - Normal
Status:  None Privacy:  Public
Assigned to:  None Percent Complete:  0%
Open/Closed:  Open Planned Release:  None
Effort:  0.00

Wed 21 Dec 2016 01:42:04 PM UTC, comment #4: 

I forget the multi-netif situation which you mention in some other thread.

There is just problem on cleanup. We should keep track the source netif of the item in the list and properly solve situation, where two or more netifs add same item to the list. After netif down, we should cleanup only items owned by that netif.

Another task is order of items for DNS lookup function.

 Jan Breuer <jan_breuer>
Wed 21 Dec 2016 01:22:00 PM UTC, comment #3: 

Ok, the problem here is not the implementation itself (one or more lists) but the specification of behaviour. Later, we can develop the implementation easily.

We should start with the specification and for now forget the original question.

We need to specify priority IPv6 over IPv4 or alternatively IPv4 over IPv6 depending on configuration.

We have these types of addresses
- Manual IPv4
- Manual IPv6
- DHCPv4 IPv4
- ND6 IPv6
- DHCPv6 IPv6

We should specify rules, what can overwrite what - example for IPv6 over IPv4 priority:
- Manual address can't be overwritten
- DHCPv4 can be overwritten by DHCPv6 and ND6
- Any IPv6 can be overwritten by newer address - lifetime should be also updated.
- Should we prioritize DHCPv6 over ND6?
- We should overwrite the oldest entry which is allowed to be overwritten
- We should be able to cleanup specific addresses from the list after network change

Many rules applies only in situation where we have limited space in the list. If there is enough space, no overwriting will be performed.

Jan Breuer <jan_breuer>
Tue 20 Dec 2016 09:01:37 PM UTC, comment #2: 

Of course that should still work. I just think the current situation is not ideal where the server will be overwritten from IPv4 to IPv6 and back again, depending on the time when your DHCP(v4) lease expires and when you'll get the next RA...

Keeping 2 seperate lists (or different indices into the same list) would fix this, but I'm open for other suggestions to get a reproducable behaviour.

 Simon Goldschmidt <goldsimon>
Group administrator
Tue 20 Dec 2016 07:10:42 PM UTC, comment #1: 

We still need to support AAAA requests from IPv4 DNS servers and vice versa. From my point of view, we don't need two lists. It will just complicate things.

 Jan Breuer <jan_breuer>
Wed 14 Dec 2016 09:15:01 PM UTC, original submission:  

Currently, both dhcp (ipv4) and dn6 (ipv6) can set servers to DNS. We might have to keep a dedicated list of servers per IP version and request both protocols in parallel for dual-stack devices...?

(i.e. request A from IPv4 server and AAAA from IPv6 server?)

 Simon Goldschmidt <goldsimon>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jan_breuer (Posted a comment)
  • -email is unavailable- added by goldsimon (Submitted the item)

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    No changes have been made to this item

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.13-461b.
    Corresponding source code