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

[Brian E Carpenter <[e-mail]>]

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.

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