RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1102728 - dnsmasq support for IPv6
Summary: dnsmasq support for IPv6
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: dnsmasq
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Nir Yechiel
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-29 12:50 UTC by Nir Yechiel
Modified: 2014-11-16 10:53 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-16 10:53:45 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Nir Yechiel 2014-05-29 12:50:00 UTC 
This is a test-only bug to make sure we have the IPv6 address assignment aspects of dnsmasq being tested:

- Stateless Address Auto Configuration (SLAAC) - RFC 4862

Nodes listen for Router Advertisements (RA) messages periodically sent out by routers on the local link, or requested by the node using an RA solicitation message, then create a Global unicast IPv6 address by combining its interface’s EUI-64 (based on MAC) and the Link Prefix (obtained via Router Advertisement). Node should be able to obtain: IPv6 prefix(es), Default router address(es), Hop limit and MTU.


- DHCPv6 - RFC 3315

Stateless - The DHCP server is not required to store any dynamic state information about any indivisual clients. The client side has no obvious DHCPv6 configuration.
Addresses are autoconfigured on the interface based on prefixes in RA messages received from the server. If received RA messages have the “other configuration” flag set, the interface will attempt to acquire the other (for example DNS, NTP) configuration from any DHCPv6 servers. 

Stateful - Functions exactly the same as traditional IPv4 DHCP in which hosts receive both their IPv6 address and additional parameters from the DHCP server. Like DHCP for IPv4, the components of a DHCPv6 infrastructure consist of DHCPv6 clients that request configuration, DHCPv6 servers that provide configuration, and DHCPv6 relay agents that convey messages between clients and servers when clients are on subnets that do not have a DHCPv6 server

Note: The only way to get a default gateway in IPv6 is via a RA message. DHCPv6 does not carry default route information at this time
 
  
Additional info:

This is one of the key pieces to enable the support for IPv6 in OpenStack Neutron dhcp-agent.
Comment 1 Tomáš Hozza 2014-06-10 12:15:41 UTC 
What is expected from me in this bug? How it will be tested?
Comment 2 Nir Yechiel 2014-07-01 08:30:29 UTC 
(In reply to Tomas Hozza from comment #1)
> What is expected from me in this bug? How it will be tested?

Hi Tomas, 

There are no specific test cases at this point, we just need a general functional/high level testing of the IPv6 features of dnsmasq as described in comment #0. The OpenStack QE team will then test the end-to-end scenarios as dictated by the OpenStack Neutron implementation.

FYI, this is the IPv6 SLAAC blueprint which is currently on track for Neutron and going to use dnsmasq: https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-slaac

Thanks,
Nir
Note You need to log in before you can comment on or make changes to this bug.