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

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

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.

> 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

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