Re: [BEHAVE] Comments on draft-korhonen-behave-nat64-learn-analysis-00

Hi,

On Nov 11, 2010, at 3:40 AM, Jacni Qin wrote:

> Dear Jouni,
> 
> Another comment, the analysis of prefixes for multicast should be included as well in the document.
> Or did I miss it?

Discovering the presence of a translator in general, the solutions for unicast vs. multicast should not make difference.. details may vary though. In order to differentiate prefix used for multicast translation and subsequent manual address synthesis the application then need to know the difference of learned prefixes. There is no specific text around this, yet.

- Jouni

> 
> 
> Cheer,
> Jacni
> 
> 
> 
> On Thu, Nov 11, 2010 at 8:39 AM, jouni korhonen <jouni.nospam@gmail.com> wrote:
> HI,
> 
> On Nov 11, 2010, at 1:27 AM, Dave Thaler wrote:
> 
> >> -----Original Message-----
> >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf
> >> Of jouni korhonen
> >> Sent: Thursday, November 11, 2010 1:49 AM
> >> To: Dave Thaler
> >> Cc: draft-korhonen-behave-nat64-learn-analysis@tools.ietf.org; 'behave'
> >> (behave@ietf.org)
> >> Subject: Re: [BEHAVE] Comments on draft-korhonen-behave-nat64-learn-
> >> analysis-00
> >>
> >> Hi Dave,
> >>
> >> Thanks for the review. See some initial comments inline.
> >>
> >> On Nov 10, 2010, at 5:15 PM, Dave Thaler wrote:
> >>
> >>> I have two main technical comments, and a bunch of smaller mostly editorial
> >> comments.
> >>>
> >>> The main technical comments are that I think it's missing a discussion of two
> >> key requirements:
> >>> 1)      Need support for applications that don't use DNS (e.g., ones that get IP
> >> literals via an application layer referral)
> >>
> >> Right. However, most hosts use DNS at some point of time and eventually
> >> applications in the host, even those not themselves using DNS, could learn the
> >> synthesized prefixes (assuming there were a way for applications to ask for
> >> synthesized prefixes known to the host). Using some kind of host wide
> >> repository would introduce additional issues though..
> >>
> >>
> >>> 2)      Need ability to learn multiple prefixes, not just one (NAT64 and DNS64
> >> docs say there can be one or more prefixes).   This even affects the title of the
> >> document.
> >>
> >> Do you mean that none of the analyzed proposals work if a single DNS response
> >> from DNS64 would contain multiple AAAA RRs and each had a different
> >> Pref64::/n ? Most if not all of the analyzed proposals actually seem to assume a
> >> single Pref64::/n at time. Some proposals do work if Pref64::/n changes e.g.
> >> between DNS responses.
> >
> > It's possible some may support multiple prefixes in multiple DNS records returned.
> 
> OK. This is a good point and unfortunately we missed that.
> 
> >
> > Any proposal that only works with a single Pref64 at a time does not meet the
> > requirements in my view.   I believe there are several proposals in the doc that
> > do not make this assumption and would work with multiple prefixes.
> 
> There are several proposals that are capable of that technically, yes.. thought they do not really state that. Taking the multiple Pref64::/n requirement into account would actually change the outcome of the analysis quite a bit and no problem with that.
> 
> - Jouni
> 
> 
> >
> > -Dave
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
> 