> -----Original Message-----
> From: marcelo bagnulo braun [mailto:
marcelo at it.uc3m.es]
> Sent: Friday, October 23, 2009 4:01 AM
> To: Dan Wing
> Cc: 'Andrew Sullivan';
behave at ietf.org
> Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64
>
> Dan Wing escribió:
> >
> >
> >
> >> -----Original Message-----
> >> From:
behave-bounces at ietf.org
> >> [mailto:
behave-bounces at ietf.org] On Behalf Of Andrew Sullivan
> >> Sent: Thursday, October 22, 2009 10:56 AM
> >> To:
behave at ietf.org
> >> Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64
> >>
> >> On Thu, Oct 22, 2009 at 10:20:13AM -0700, Cameron Byrne wrote:
> >>
> >>
> >>> This is why i am suggesting that the DNS64 have a hand in
> >>>
> >> either "dumb
> >>
> >>> round robin" or "intelligent NAT64 system aware" load
> sharing, since
> >>> DNS64 is assigning the PREF64 to the client resolver, it is
> >>>
> >> the driver
> >>
> >>> directing the load on the network / NAT64. This is an important
> >>> point. The DNS64 system drives the load to unique PREF64 /
> >>>
> >> NAT64 that
> >>
> >>> is hosted on a specific location in the network topology.
> >>>
> >> One of the
> >>
> >>> main advantages of DNS64/NAT64 is that it is not required
> to be part
> >>> of shortest path routing topology between the user and the content
> >>> like NAT-PT was, thus the entire system encourages and
> benefits from
> >>> NAT-free end to end IPv6 communication. The DNS64 / PREF64
> >>>
> >> provides a
> >>
> >>> very elegant detour from the shortest path string of
> >>>
> >> routers and into
> >>
> >>> a NAT64 service specific / optimized node, only when NAT64
> >>>
> >> is needed.
> >>
> >> This view is exactly how we got so much sludge from
> various local DNS
> >> systems leaking out onto the Internet. For instance, we
> have a _whole
> >> system_ (the AS112 system) of anycast name servers just to sink the
> >> traffic that used to arrive at the in-addr.arpa zone due
> to RFC 1918
> >> address space allocations. The idea that these DNS answers are not
> >> going to leak, are not going to get out onto the wider
> Internet, and
> >> so on is completely fanciful. They will, and the only
> question is how
> >> we can arrange things so that they do the least damage.
> >>
> >> Therefore, the trickier the strategy one proposes for
> DNS64, the more
> >> my alarm bells ring. I think we want to take DNS64 for
> what it is --
> >> a cute trick that allows us to make two completely
> different networks
> >> talk to one another -- and accept that, as all cute
> tricks, it has a
> >> number of limitations some of which will be, "Performance
> is rotten."
> >> Anything that smacks of DNS tricks that already break all over the
> >> place in the plain old DNS world (and that will break even more as
> >> DNSSEC gets turned on) sounds to me like the sort of trouble we
> >> shouldn't be borrowing. I'm aware that people are going
> to do those
> >> things, but if I have to give them the sort of advice that
> will really
> >> help them with deployment, my advice is "don't".
> >>
> >
> >
> > It's important that, as best we can, the public IPv4 address stay
> > the same for all translations by a client. Otherwise
> > some applications will break. FTP certainly breaks. Other
> > IP-based auth/authz systems break, too, and I am told some
> > websites use cookies that encode IP addresses. That's why
> > REQ-1 is written in
> >
http://tools.ietf.org/html/draft-nishitani-cgn-02#section-3
> >
> > If the DNS64 were to change the Prefix as a NAT64's load changed,
> > it would cause flows to take a different NAT64. If that different
> > NAT64 is not sharing state with other NAT64s, a different public
> > IPv4 address would be assigned.
> >
> > So, a safer approach is to load balance when the IPv6 address is
> > assigned, using DHCPv6 to assign a DNS64 to a host is safer, and
> > have that DNS64 always use the same Prefix for its synthesized
> > answers. This is a natural thing to do, anyway -- if you have
> > 5 NAT64 devices you want 20% of users to go to each one. So
> > 20% of your users are pointed to one DNS64, 20% to another
> > DNS64, and so on. Each DNS64 could, actually, be the same
> > DNS64 box -- which means for this scheme the DNS64 should use
> > the *destination* address of the arriving DNS query (rather
> > than source address) to decide which Prefix to use in the
> > synthesized response.
> right, this seems cleaner to me as well
>
> > Would that be reasonable to put into
> > the DNS64 spec?
>
> mmm, afaict this doens't change the spec at all.
