RE: translator friendly DNS Proxy

[<H.Miyata@jp.yokogawa.com>]

Oops,

Sorry, I would like to maintain it available.
Thanks for your comments.

Thanks,

.....miyata

________________________________________
差出人: Dan Wing [dwing@cisco.com]
送信日時: 2008年9月4日 7:39
宛先: Endou, Masahito (Masahito.Endou@jp.yokogawa.com); v6ops@ops.ietf.org
CC: behave@ietf.org; Miyata, Hiroshi (H.Miyata@jp.yokogawa.com)
件名: RE: translator friendly DNS Proxy

> -----Original Message-----
> From: Masahito.Endou@jp.yokogawa.com
> [mailto:Masahito.Endou@jp.yokogawa.com]
> Sent: Thursday, August 07, 2008 8:02 PM
> To: dwing@cisco.com; v6ops@ops.ietf.org
> Cc: behave@ietf.org; H.Miyata@jp.yokogawa.com
> Subject: RE: translator friendly DNS Proxy
>
> Hi, Dan
>
> > > Hi, all
> > >
> > > I submitted this document.
> > >
> > > In this document, I proposed DNS proxy that is separated
> > from NAT-PT.
> > > This document describes about relationship DNS proxy and
> sNATPT[1].
> > > I think that this DNS proxy can collabolate with other translation
> > > technologies.
> > >
> > > I know that this working group isn't appropriate to discuss
> > such kind
> > > items, but I informed this document bacause many people that are
> > > interested in subscribed this mailing list.
> > > And, if there is more suitable working group to discuss it, please
> > > tell me that.
> >
> > The Behave working group would be best,
> > <http://www.ietf.org/html.charters/behave-charter.html>.  I
> > just forwarded your announcement to the Behave mailing list.
>
> Thanks for your information.
> I just subscribed :)
>
> > > [1] sNATPT: Miyata, H., "Simplified Network Address Translation -
> > > Protocol Translation"
> > >                    draft-miyata-v6ops-snatpt-00
> >
> > I read your draft, and it seems like the Translator Interface
> > is the key -- it is the interface between the DNS Proxy
> > (which synthesizes AAAA records) you describe, and the NAT-PT
> > itself (which NATs between v6 and v4).
> >
> > Do I understand correctly?
>
> Yes.
> But actual key point is that the translator interface can
> separate DNS Proxy from NAT-PT.
>
> If a translator has NAPT-PT rule for IPv6 to IPv4
> translation, the translator interface is not required.
> In this case, a translator maps a lot of IPv6 source
> addresses to one IPv4 source address,
> so DNS Proxy doesn't need to care an IPv4 source address.

(Sorry for my delay.)

I noticed that draft-miyata-v6ops-snatpt-00 has expired.  Did you want to
continue discussing it?  We have not included it in the upcoming comparison
document.


In the draft-miyata-v6ops-snatpt-00:

In the IPv6->IPv4 direction, the separation of DNS rewriting ("DNS-ALG") from
NATing seems very similar to draft-bagnulo-behave-nat64-00.  Can you describe
the differences, if any, between draft-miyata-v6ops-snatpt-00 and
draft-bagnulo-behave-nat64-00?

In the IPv4->IPv6 direction, Section 5.2 of draft-miyata-v6ops-snatpt-00
describes that both static v4->v6 mapping and dynamic v4->v6 mapping can be
supported.  The text appears to go on to describe dynamic mapping.  I believe
we would only need static mapping from IPv4->IPv6, as described very briefly
in Section 6 of draft-miyata-v6ops-snatpt-00.

-d

> best regards,
>
> // masaxmasa
>
> > -d
> >
> >
> > > Thanks your comments.
> > > Best Regards,
> > >
> > > --------------------------
> > > A new version of I-D, draft-endo-v6ops-dnsproxy-00.txt has been
> > > successfuly submitted by Masahito Endo and posted to the IETF
> > > repository.
> > >
> > > Filename:        draft-endo-v6ops-dnsproxy
> > > Revision:        00
> > > Title:           Translator Friendly DNS Proxy
> > > Creation_date:   2008-08-07
> > > WG ID:           Independent Submission
> > > Number_of_pages: 24
> > >
> > > Abstract:
> > > This document describes the DNS Proxy that is separated
> from NAT-PT
> > > [RFC2766].  NAT-PT was designed to work with DNS Application Level
> > > Gateway.  However [RFC4966] pointed out DNS related issues, and
> > > [RFC2766] was changed to historical state.  This document
> > attempts to
> > > DNS Proxy specification, removing dependency on NAT-PT as well as
> > > resolving problems pointed in [RFC4966].
> > >
> > > // masaxmasa
> > >
> >
> >
>