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

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

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.

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

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