Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-00.txt

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Nov 2011 09:27:26 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Brian E Carpenter
> Sent: Monday, October 31, 2011 1:22 PM
> To: Prashanth Patil
> Cc: [email-masked]
> Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-
> 00.txt
> 
> I don't get it. If a host is dual stacked it can be configured with
> any DNS server, as long as it is not a DNS64. If you can have a
> DNS64 directly visible, and a v4-only DNS server directly visible,
> you are on a dual stack network, so you can also have a dual stack
> DNS server directly visible.

It is anticipated that a network will have a mix of IPv4-only,
IPv6-only, and dual-stack hosts.  The hosts don't know if they
need a 'normal' DNS server or a DNS64, nor do we have a way
to tell them the difference.

This I-D attempts to provide a solution to that problem of a 
network with a mix of hosts that need to be configured with a 
'normal' DNS server and DNS64 server.  We believe the underlying 
idea (to "poke" a host to tell it something changed on the 
network) appears to have other applicability beyond the DNS/DNS64
use-case, as well.

-d

> Regards
>    Brian Carpenter
> 
> On 2011-11-01 05:05, Prashanth Patil wrote:
> > Hi Brian,
> > The idea behind the proposal is to provision a means by which traffic
> is
> > sent using IPv4 and not through the IPv6/IPv4 translator. The
> advantage
> > being that if NAT44 and NAT64 are deployed on the same network, it is
> > preferable to use NAT44 over NAT64 because of scale, performance and
> > application incompatibility issues (e.g., FTP) [RFC6384].
> > A "normal" DNS server does not have DNS64 capability. The IPv4-mapped
> > address for this "normal" server ensures that it can be reached only
> by
> > IPv4š. So if a host is IPv4-only, it will send a DNS query to the
> "normal"
> > server just to get the A records. If the host is dual-stack it will
> also
> > send a DNS query to the "normal" server to get both A and AAAA
> records. If
> > the destination address is an IPv4 address,  dual-stack host just
> gets A
> > records but not synthesized AAAA records. So this technique will
> ensure that
> > IPv4 is preferred over the IPv6/IPv4 translator prefix and also gives
> native
> > IPv6 higher precedence than IPv4.
> > If the host happens to be IPv6 only, then it cannot reach the
> "normal"
> > server because it has IPv4-mapped prefix as explained previously. So
> IPv6
> > only host can only reach DNS64 server. So this host will send the DNS
> query
> > to DNS64 to get AAAA records. Based on the destination address the
> host will
> > get IPv4-embedded IPv6 address or just the global IPv6 address.
> >
> > šNote: From RFC 6052
> > ³When presented with the IPv4-mapped prefix, current versions of
> Windows and
> > Mac OS generate IPv4 packets, but will not send IPv6 packets.²
> >
> > -Prashanth
> >
> > On 22/10/11 6:20 AM, Brian E Carpenter wrote:
> >> I have a basic question. Why does this draft define a 'normal'
> >> DNS server as one having an IPv4-mapped IPv6 address?
> >>
> >> That seems like a completely *abnormal* DNS server for a dual
> >> stack host. A dual stack host should normally have a DNS server
> >> with a regular IPv6 address that will return both A and AAAA
> >> records if they exist. Normally the server will be dual stacked
> >> anyway, and will return exactly the same response whether the
> >> query arrives via v4 or v6.
> >>
> >> A DNS server which only has an IPv4 address will also return
> >> A and AAAA records if they exist, so there is absolutely no
> >> difference as far as the dual stack host is concerned anyway.
> >> So what is the point in using the IPv4-mapped address?
> >>
> >> Regards
> >>     Brian
> >>
> >> On 2011-10-18 11:17, [email-masked] wrote:
> >>> A New Internet-Draft is available from the on-line Internet-Drafts
> >>> directories.
> >>>
> >>>     Title           : DHCPv6 Dynamic Re-Configuration
> >>>     Author(s)       : Dan Wing
> >>>                            Tirumaleswar Reddy
> >>>                            Prashanth Patil
> >>>     Filename        : draft-wing-behave-dhcpv6-reconfigure-00.txt
> >>>     Pages           : 10
> >>>     Date            : 2011-10-17
> >>>
> >>>     Some networks are expected to support IPv4-only, dual-stack,
> and
> >>>     IPV6-only hosts at the same time.  This makes prioritizing the
> DNS
> >>>     servers for hosts tricky due to a heterogeneous mix of protocol
> >>>     stacks causing optimal behavior to occur only when the host
> stack re-
> >>>     initializes.  The networks infrastructure is usually well
> equipped to
> >>>     be aware of single/dual-stack nature of hosts.  This
> specification
> >>>     extends DHCPv6 so that the DHCPv6 Relay Agent can dynamically
> >>>     influence the priority of DNS servers provided to the host, so
> that
> >>>     the host can use the optimal DNS server for resolution.
> >>>
> >>>
> >>> A URL for this Internet-Draft is:
> >>> http://www.ietf.org/internet-drafts/draft-wing-behave-dhcpv6-
> reconfigure-00.t
> >>> xt
> >>>
> >>> Internet-Drafts are also available by anonymous FTP at:
> >>> ftp://ftp.ietf.org/internet-drafts/
> >>>
> >>> This Internet-Draft can be retrieved at:
> >>> ftp://ftp.ietf.org/internet-drafts/draft-wing-behave-dhcpv6-
> reconfigure-00.tx
> >>> t
> >>> _______________________________________________
> >>> I-D-Announce mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/i-d-announce
> >>> Internet-Draft directories: http://www.ietf.org/shadow.html
> >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>>
> >> _______________________________________________
> >> Behave mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/behave
> >
> >
> >
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Nov 2011 11:50:47 +1100

The best way to identify a mapped response is for the DNS64 server
to flag it and as *every* IPv6 node is supposed to be EDNS capable
a EDNS option can be used to signal this.

getaddrinfo would just filter DNS64 responses when it is asking for
both address families.  Dual stack applications would just see the
IPv4 addresses.  IPv6 only apps would see the mapped addresses.

Recursive servers talking to forwarders would set the option on
AAAA queries and record the respone along with any AAAA records.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 6 Nov 2011 15:55:32 +0530

The advantage with the proposal suggested in the draft is that it
requires no changes to host and DNS64 server. The idea is to provide a
framework where, based on changes in host or network characteristics,
Relay agents can dynamically inform the DHCPv6 server to update the host
with new/updated configuration information. In addition, the concept of
informing the DHCPv6 server by the network could be extended to other
use cases as well.
Just like EDNS0 draft-boucadair-behave-dns-a64-02 proposes a model where
A64 record for IPv4-Embedded IPv6 address is used so as to distinguish
from native IPv6 address using AAAA records. Our proposed draft  ensures
that, as per RFC 3484, IPv6 address list (not IPv4-embedded IPv6)
followed by IPv4 addresses are provided so that native IPv6 is given
higher priority over IPv4. Since IPv4-embedded IPv6 addresses are not
provided - there is no need for destination address selection algorithm
to pick IPv4 over IPv4-embedded IPv6 addresses, which would require the
policy table to be updated with network's IPv6/IPv4 translator's prefix
or well-known prefix 64:FF9B::/96 as the lowest Precedence in the
address selection rules.

--Tiru.

------ Forwarded Message
From: Mark Andrews <[email-masked]>
Date: Wed, 02 Nov 2011 11:50:47 +1100
To: Dan Wing <[email-masked]>
Cc: 'Brian E Carpenter' <[email-masked]>, 'Prashanth Patil'
<[email-masked]>, <[email-masked]>
Subject: Re: [BEHAVE] I-D Action:
draft-wing-behave-dhcpv6-reconfigure-00.txt

------ End of Forwarded Message

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 07 Nov 2011 09:19:55 +1300

> to tell them the difference.

Indeed not, it is for the DHCPv6 server to ensure that the IPv6-only
hosts are pointed to the abnormal DNS server (i.e. the DNS64 server).
I'm left very uncomfortable by this kludge. Forcing dual-stack hosts
to resolve DNS via IPv4 seems backwards.

Also, how will this help on a network that is using RFC 6106?
DHCPv6 isn't mandatory afaik.

    Brian

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Nov 2011 12:10:54 -0800

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Sunday, November 06, 2011 12:20 PM
> To: Dan Wing
> Cc: 'Prashanth Patil'; [email-masked]

Our proposal does not force dual-stack hosts to resolve DNS using
IPv4 transport (DNS-over-IPv4).

> DHCPv6 isn't mandatory afaik.

The RA-versus-DHCPv6 controversy is not unique to this idea,
of course.

Let's see if the idea has merit; if it does, we can describe
how to provide similar functionality using unicast RA.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Nov 2011 14:58:43 +1300

Dan,

> IPv4 transport (DNS-over-IPv4).

I must have misunderstood again. It seems to me that this is exactly
the effect of the following process:

   1.  *IPv6-only transition to Dual-Stack* In case a host is IPv6-only
       to start off, it is provided a DNS64 Server.  When transitioning
       to dual-stack, a IPv4 DNS Server is assigned as a consequence of
       obtaining an IPv4 Address.  The DHCPv6 Relay Agent can detect
       this and send RELAY-RECONFIG message Section 4.1 to the DHCPv6
       Server indicating that the host needs to be needs to be provided
       with "normal" DNS Server followed by DNS64 server.

That would give it an IPv4-mapped address for DNS service, which it would
therefore access using native IPv4.

Regards
   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Nov 2011 19:09:53 -0800

> Sent: Tuesday, November 08, 2011 5:59 PM
> To: Dan Wing
> That would give it an IPv4-mapped address for DNS service, which it
> would therefore access using native IPv4.

Ah, because we define:

   'normal' DNS server : DNS server using an IPv4-mapped IPv6 address
   (that is, an IPv6 address starting with ::ffff:/96 IPv4-mapped
   prefix).  Hosts can communicate with 'normal' DNS server only using
   IPv4 packets [RFC6052], section 4.2.

Yes, agreed, that is how the text is written.  This whole idea was
built around "how can we improve draft-wing-behave-dns64-config",
which did the IPv4-mapped address trick -- that trick just doesn't
always work.

So, until we can update the I-D, imagine that the definition of
"normal DNS server" is "a DNS server that is not performing DNS64
functions".  Said another way, "normal DNS server" is a normal
DNS server that is found on nearly 100% of networks today that
does not synthesize AAAA records.

With that change, would you have an objection?

But, back to your objection -- what's the problem with a dual-stack
host sending its DNS queries over IPv4?  The only issue I see is
 1. it is impure
 2. if IPv4 address sharing is on the path between the client and
    DNS server, the DNS queries will consume UDP and TCP ports. 
Are there other objections to sending DNS queries over IPv4?

-d

> >>>>> being that if NAT44 and NAT64 are deployed on the same network,
> it
> >> is

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Nov 2011 16:33:23 +1300

Hi again,

> With that change, would you have an objection?

Sure, we can separate the issues that way.

> host sending its DNS queries over IPv4?  The only issue I see is

As are many aspects of DNS64, so I suppose we have to ignore that.

>     DNS server, the DNS queries will consume UDP and TCP ports. 

True, but for a network of any size, that would be crazy placement
of the DNS server, IMHO.

> Are there other objections to sending DNS queries over IPv4?

It goes against the general strategy of getting as much traffic
as possible onto v6 (assuming equal efficiency).

I think this matters sociologically. On a network with equal numbers
of v4-only, v6-only and dual stack hosts, we would see 67% of DNS
traffic still over v4, instead of 67% already over v6. The message
to management is very different.

I can't pretend that this is a technical objection ;-)

   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Nov 2011 19:46:00 -0800

> Sent: Tuesday, November 08, 2011 7:33 PM
> To: Dan Wing

Agreed.

But some parents use "parental control" DNS servers, some geeks
use Google's or HE's nameservers, and some corporate users use
their company's "hidden" (unpublished) nameservers (split-zone 
DNS).  Those will cross a NAT.

> I can't pretend that this is a technical objection ;-)

Ok.

I'm trying to see if there is a technical objection somewhere
in there; I think sending DNS queries over a NAT is one.  But,
that can be handled reasonably well by vendors doing fancier
things for port 53 (e.g., shorter time outs).

-d

> >>>>>>> preferable to use NAT44 over NAT64 because of scale,
> performance
> >>>> and
> >>>>>>> server because it has IPv4-mapped prefix as explained
> previously.
> >>>> So
> >>>>>> IPv6
> >>>>>>> only host can only reach DNS64 server. So this host will send
> the
> >>>> DNS
> >>>>>> query
> >>>>>>>>>     IPV6-only hosts at the same time.  This makes
> prioritizing
> >>>> the
> >>>>>> DNS
> >>>>>>>>>     influence the priority of DNS servers provided to the
> host,
> >>>> so
> >>>>>> that