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

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Tuesday, November 08, 2011 7:33 PM
> To: Dan Wing
> Cc: 'Prashanth Patil'; [e-mail]
> Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-reconfigure-
> 00.txt
> 
> Hi again,
> 
> On 2011-11-09 16:09, Dan Wing wrote:
> >> -----Original Message-----
> >> From: Brian E Carpenter [mailto:[e-mail]]
> >> Sent: Tuesday, November 08, 2011 5:59 PM
> >> To: Dan Wing
> >> Cc: 'Prashanth Patil'; [e-mail]
> >> Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-
> reconfigure-
> >> 00.txt
> >>
> >> Dan,
> >>
> >>> Our proposal does not force dual-stack hosts to resolve DNS using
> >>> 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.
> >
> > 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?
> 
> Sure, we can separate the issues that way.
> 
> > 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
> 
> As are many aspects of DNS64, so I suppose we have to ignore that.
> 
> >  2. if IPv4 address sharing is on the path between the client and
> >     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.

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.

> > 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 ;-)

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


>    Brian
> 
> >
> > -d
> >
> >
> >> Regards
> >>    Brian
> >>
> >> On 2011-11-08 09:10, Dan Wing wrote:
> >>>> -----Original Message-----
> >>>> From: Brian E Carpenter [mailto:[e-mail]]
> >>>> Sent: Sunday, November 06, 2011 12:20 PM
> >>>> To: Dan Wing
> >>>> Cc: 'Prashanth Patil'; [e-mail]
> >>>> Subject: Re: [BEHAVE] I-D Action: draft-wing-behave-dhcpv6-
> >> reconfigure-
> >>>> 00.txt
> >>>>
> >>>> On 2011-11-02 05:27, Dan Wing wrote:
> >>>>>> -----Original Message-----
> >>>>>> From: [e-mail] [mailto:[e-mail]]
> On
> >>>>>> Behalf Of Brian E Carpenter
> >>>>>> Sent: Monday, October 31, 2011 1:22 PM
> >>>>>> To: Prashanth Patil
> >>>>>> Cc: [e-mail]
> >>>>>> 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.
> >>>> 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.
> >>> Our proposal does not force dual-stack hosts to resolve DNS using
> >>> IPv4 transport (DNS-over-IPv4).
> >>>
> >>>> Also, how will this help on a network that is using RFC 6106?
> >>>> 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
> >>>
> >>>
> >>>>     Brian
> >>>>
> >>>>> 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, [e-mail] 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
> >>>>>>>>> [e-mail]
> >>>>>>>>> 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
> >>>>>>>> [e-mail]
> >>>>>>>> https://www.ietf.org/mailman/listinfo/behave
> >>>>>> _______________________________________________
> >>>>>> Behave mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/behave
> >>>
> >
> >