Subject: [BEHAVE] Benefit to DNS64//re: Comments on draft-wing-behave-learn-prefix-03

From: Xu Xiaohu <[email-masked]>
Date: Fri, 24 Jul 2009 17:47:58 +0800

Hi all,

Enlightened by Dave's comments, I just realized that the DNS64
(draft-ietf-behave-dns64-00) can benefit from the prefix64 learning
mechanisms defined in draft-wing-behave-learn-prefix at least in the
following two cases :

1) Distinguish native IPv6 addresses from synthesized IPv6 addresses.

Consider a scenario where unmodified hosts and upgraded hosts co-exist in
the same network. The DNS64 server will return AAAA records (either native
or synthesized) to DNS clients no matter they are unmodified hosts or not.
For upgraded dual-stack hosts, they can identify whether the IPv6 addresses
in the AAAA records are native or not by using the learnt prefix64, if the
addresses are synthesized addresses, they can choose IPv4 addresses for
communication.

2)  An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-resolver mode

As stated in section 6.1.2 of the DNS64 draft,  "H1 needs to know the prefix
assigned to the local IPv6/IPv4 Translator (Pref64::/n).  For the purpose of
this example, we assume it learns this through manual configuration". 

IMHO, the manual configuration is not a good option. In contrast, with one
of the prefix64 learning mechanisms defined in
draft-wing-behave-learn-prefix, the end hosts could learn the prefix64
automatically. This not only reduces the configuration burden, but also
avoids the possible mis-configuration. 

Any comment?

XIaohu

> -----邮件原件-----
> 发件人: Xu Xiaohu [mailto:[email-masked]] 
> 发送时间: 2009年7月23日 10:59
> 收件人: 'Dave Thaler'; [email-masked]'; [email-masked]'
> 抄送: 'Behave WG'
> 主题: re: [BEHAVE] Comments on draft-wing-behave-learn-prefix-03
> 
> Hi Dave,
> 
> > > Comment [DT1]: This is not the only (or perhaps even the most
> > > important)
> > > reason to learn the prefix. Another reason is to do appropriate 
> > > sorting of
> > > IPv6 addresses between native vs translated.
> > >
> > > [XH]: Once one uses one of the mechanisms described in this
> > draft to
> > > learn the prefix64 and uses it to synthesize IPv6 
> addresses,  is it 
> > > still necessary to use other mechanisms (e.g. DNS64) to 
> obtain the 
> > > translated addresses?
> > 
> > I think your question is whether plain DNS (not DNS64) can 
> be used if 
> > you do synthesis in the host.  I believe the answer is yes, 
> but DNS64 
> > is still needed for unmodified hosts in the same network.
> 
> I guess your point is : The unmodified hosts co-exsit with 
> the upgraded hosts in the same network. The DNS64 will return 
> them the AAAA records (either native or synthesized) 
> corresponding to the AAAA request, no matter they are 
> unmodified or not. For upgraded hosts, they can identify 
> whether the received AAAA record is native IPv6 address or 
> not by using the learnt prefix64. If the end-host is 
> dual-stack and the received IPv6 address is synthesized, it 
> can use the IPv4 address for communication.
> 
> Is my understanding right? 
> 
> > The other thing to keep in mind is that applications use a 
> variety of 
> > mechanisms, which might be implemented in the application or in the 
> > host OS.  My main point however was that the prefix is needed for 
> > reasons other than just synthesis.
> 
> Yes, I fully agree.
> 
> > It also occurs to me that if you're doing synthesis in the end host 
> > you need more than just the prefix (learning the prefix only is 
> > sufficient for distinguishing native from translated though).
> > Specifically you need to know what algorithm is used after 
> the prefix.  
> > So either the whole world has to agree on only one, or else 
> there has 
> > to be some identifier that allows extensibility in the 
> future.  Which 
> > of those two possibilities is the right one is an open issue.
> 
> Maybe we should extend a field to identify the algorithms for 
> address synthesis.
>  
> > > Comment [DT15]: Disadvantage is configuring the information
> > in every
> > > router, rather than only in a small number of DHCP or DNS servers.
> > >
> > > [XH] :Yes, the manual configuration option for the RA
> > mechanism is not
> > > optimal. Hence, we introduce some extention to the IGP ( 
> e.g., OSPF 
> > > Router Information Opaque LSA ) for advertising the
> > prefix64. In this
> > > way, the edge routers could learn the prefix64
> > automatically which not
> > > only reduces the manual configuration task but also avoid the 
> > > possibility of mis-configuartion.
> > 
> > Yes, and that's significantly more complex than either of the other 
> > two alternatives in the doc, especially because of the variety of 
> > IGPs.
> 
> Yes, the extention to IGP will introuce some complexity, 
> However, this method can avoid mis-configuration and 
> reconfiguration when the prefix64 of the translator changed. 
> By the way, the extention of IGP (e.g., a new TLV of the OSPF 
> RI opaque LSA) is transparent to the internal routers. In 
> other words, only the translator routers and the edge routers 
> need upgrade. The internal routers which don't know this 
> extension will flood the LSAs as normal.
> 
> If we have to reduce the number of the possible mechanisms 
> for prefix64 learning, I prefer the DHCP and the RA options, 
> rather than the DNS option. The reason is: 1)  DHCP and RA 
> are two basic mechanisms for IPv6 address auto-configuration, 
> relying on some extension to either of them is reasonable; 2) 
> The DNS server used by the end hosts (or some applications on 
> the end-host ) may not be the local DNS server operated by 
> the same operator of the IPv6 site network where the end 
> hosts are located. One example is: some applications prefer 
> to use the intelligent third-party DNS server, which could 
> provider the nearest server address according to the client's 
> address, rather than the default DNS server learnt from the 
> DHCP option. Of course, it would be better if we could remain 
> all three mechanisms.
> 
> Xiaohu
> 
> 
>  _______________________________________________
> > Behave mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/behave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 24 Jul 2009 12:01:05 +0200

> addresses are synthesized addresses, they can choose IPv4 addresses for
there are several ways to handle this situation

one is as you say, if the upgraded hosts know the prefix

the other one, is that dns64 and dns services are provided throug
different IP addresses.
So upgraded hosts will have the ip address of the dns service while the
non upgraded hosts will have the ip address fo the dns64 service.

> avoids the possible mis-configuration. 

sure, if the LIR prefix is used, using one fo the techniques described
in Dan's draft is clearly needed fro a simple deployment
OTOH, if the WK prefix is used, then the WK prefix can be hardcoded in
the host, so no additional tools are needed.

But i guess we agree

Regards, marcelo

---

From: Xu Xiaohu <[email-masked]>
Date: Sat, 25 Jul 2009 08:28:03 +0800

> > Consider a scenario where unmodified hosts and upgraded 
> hosts co-exist 
> > in the same network. The DNS64 server will return AAAA 
> records (either 
> > native or synthesized) to DNS clients no matter they are 
> unmodified hosts or not.
> > For upgraded dual-stack hosts, they can identify whether the IPv6 
> > addresses in the AAAA records are native or not by using the learnt 
> > prefix64, if the addresses are synthesized addresses, they 
> can choose 
> > IPv4 addresses for communication.
> >   
> the other one, is that dns64 and dns services are provided 
> throug different IP addresses.
> So upgraded hosts will have the ip address of the dns service 
> while the non upgraded hosts will have the ip address fo the 
> dns64 service.

Then the DHCP or RA should be extended if one uses them, rather than the
manual configuration, for learning the addresses of DNS and DNS64 servers,
right?

> > 2)  An-IPv6-network-to-IPv4-Internet setup with DNS64 in 
> stub-resolver 
> > mode
> >
> > As stated in section 6.1.2 of the DNS64 draft,  "H1 needs 
> to know the 
> > prefix assigned to the local IPv6/IPv4 Translator 
> (Pref64::/n).  For 
> > the purpose of this example, we assume it learns this 
> through manual configuration".
> >
> > IMHO, the manual configuration is not a good option. In 
> contrast, with 
> > one of the prefix64 learning mechanisms defined in 
> > automatically. This not only reduces the configuration burden, but 
> > also avoids the possible mis-configuration.
> >
> >   
> 
> sure, if the LIR prefix is used, using one fo the techniques 
> described in Dan's draft is clearly needed fro a simple 
> deployment OTOH, if the WK prefix is used, then the WK prefix 
> can be hardcoded in the host, so no additional tools are needed.

Agree.

Best regards,

Xiaohu
> >> I guess your point is : The unmodified hosts co-exsit with the 
> >> upgraded hosts in the same network. The DNS64 will return them the 
> >> AAAA records (either native or synthesized) corresponding 
> to the AAAA 
> >> request, no matter they are unmodified or not. For upgraded hosts, 
> >> they can identify whether the received AAAA record is native IPv6 
> >> address or not by using the learnt prefix64. If the end-host is 
> >> dual-stack and the received IPv6 address is synthesized, 
> it can use 
> >> the IPv4 address for communication.
> >>
> >> Maybe we should extend a field to identify the algorithms 
> for address 
> >> synthesis.
> >>  
> >>     
> >> Yes, the extention to IGP will introuce some complexity, However, 
> >> this method can avoid mis-configuration and 
> reconfiguration when the 
> >> By the way, the extention of IGP (e.g., a new TLV of the OSPF RI 
> >> opaque LSA) is transparent to the internal routers. In 
> other words, 
> >> only the translator routers and the edge routers need upgrade. The 
> >> internal routers which don't know this extension will 
> flood the LSAs 
> >> as normal.
> >>
> >> If we have to reduce the number of the possible mechanisms for 
> >> prefix64 learning, I prefer the DHCP and the RA options, 
> rather than 
> >> the DNS option. The reason is: 1)  DHCP and RA are two basic 
> >> mechanisms for IPv6 address auto-configuration, relying on some 
> >> extension to either of them is reasonable; 2) The DNS 
> server used by 
> >> the end hosts (or some applications on the end-host ) may 
> not be the 
> >> local DNS server operated by the same operator of the IPv6 site 
> >> network where the end hosts are located. One example is: some 
> >> applications prefer to use the intelligent third-party DNS server, 
> >> which could provider the nearest server address according to the 
> >> client's address, rather than the default DNS server 
> learnt from the 
> >> DHCP option. Of course, it would be better if we could remain all 
> >> three mechanisms.
> >>
> >> Xiaohu
> >>
> >>