Re: [BEHAVE] two ideas - draft-wing-behave-dns64-config-02

[Dacheng Zhang <[e-mail]>]

^_^

 

> I don't understand what is meant by "have been already encapsulated"; 

> DNS64 does the synthesis on-the-fly, so they are not "already" 

> synthesized AAAA responses.  Could you clarify?

> 

 

I got the idea from draft-ietf-behave-dns64-06. In section 7.3 "Example of
IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server mode", there are
following statements: "... One option is to modify the DNS server that
receives the dynamic DNS updates.  That would normally be the authoritative
server for the zone.  So the authoritative zone would have normal AAAA RRs
that are synthesized as dynamic updates occur. " 

 

Assume there is a dual stack host in network1 intends to access an IP v4
host in network 2. It first tries to connect its resolver which integrated
with the DNS64 function using DNSsec. The resolver then queries the
authoritative DNS server of network2 to check whether there is an AAAA
record of the IPv4 host. Because the AAAA record has been generated
previously, it will be sent back to the resolver without breaking the
security requirement of DNSsec. In addition, because the IPv6 address can be
generated by a Network specified prefix and the IPv4 address, it is
difficult for the dual stack host to distinguish it from ordinary IPv6
address. 

 

Hope I've understood this problem correctly, and it will be nice if I can
your further comments. ^_^

 

 

> > maybe it is a good idea to specify a new flag in the DNS answer 

> > containing an AAAA RR. The flag indicates that a synthesized address 

> > is contained in the RR. An updated dual-stack host can recognize it 

> > while conventional ones will just ignore the flag.

> 

> I vaguely recall there was a proposal to do that, but I can't remember 

> the name of the I-D or the section of some other I-D.  I can certainly 

> add that to draft-wing-behave-dns64-config,

 

I didn't see that draft before. So, if you find it, could you please forward
me the title?

 

> and I believe it would have positives and negatives nearly identical 

> to Section 3.2, namely:

> 

> Advantages:

>   * It is simple

> 

This solution can support the scenario of IPv6 Internet to IPv4 network.
Maybe this is an advantage?

 

> Disadvantages:

>   * It requires dual-stack host to understand the new flag if

>     if it wants to avoid using the NAT64

> 

> Are there other advantages or disadvantages?

> 

> I'm not sure of the implications of the host transitioning from 

> dual-stack to IPv6-only.  Thoughts on that?

 

If the host is IPv6 only, it can ignore the flag and use the IPv6 address.
It is just my humble opinion...

 

> 

> > 2. In the sections 3.5 and 3.6, solutions of using DHCP to identify 

> > dual stack host are introduced. I want to know whether it is another 

> > feasible solution to define an option for dual stack hosts. If such 

> > an option is attached in a request from a host, the DHCP server will 

> > ensure that the host has a dual-stack.

> 

> It seems reasonable for the DHCP Request to indicate "I am 

> dual-stack".

> 

> Advantages:

>   * Simple

> 

> Disadvantages:

>   * It requires dual-stack host to include this new DHCP

>     option if it wants to avoid using the NAT64

 

Another disadvantage:

    * DHCP servers need to be updated to understand the option.

> 

> How would a host transition from dual-stack to IPv6-only in that case?  

> It seems that if it releases its IPv4 address, and becomes IPv6-only, 

> it would need to re-DISCOVER, and indicate "I am not dual stack" (or 

> perhaps not send the option?).

 

Only dual stack hosts need to send that option...

 

> 

> -d

> 

> _______________________________________________

> Behave mailing list

> [e-mail]

> https://www.ietf.org/mailman/listinfo/behave