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: 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
> >
> >