Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64

From: Jacni Qin <[email-masked]>
Date: Mon, 2 Nov 2009 23:25:58 +0800

hi Dan,

yes,
i posted a draft to v6ops, draft-qin-v6ops-icp-transition-00, which talks
about using these protocols, just in one scenario "the server side".
as you mentioned here, maybe we should document practical things like this.

On Fri, Oct 23, 2009 at 10:45 PM, Dan Wing <[email-masked]> wrote:

>
>
> > -----Original Message-----
> > From: marcelo bagnulo braun [mailto:[email-masked]]
> > Sent: Friday, October 23, 2009 4:01 AM
> > To: Dan Wing
> > Cc: 'Andrew Sullivan'; [email-masked]
> > Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64
> >
> > Dan Wing escribió:
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: [email-masked]
> > >> [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> > >> Sent: Thursday, October 22, 2009 10:56 AM
> > >> To: [email-masked]
> > >> 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.
>
> Agreed.
>
> > I think it may make sense to document reccomended deployment
> > practices (with cool tricks like this one), but maybe in
> > a separated BCP document?
>
> That sounds reasonable.
>
> -d
>
>
> > Regards, marcelo
> >
> >
> >
> >
> > > -d
> > >
> > >
> > >
> > >> A
> > >>
> > >> --
> > >> Andrew Sullivan
> > >> [email-masked]
> > >> Shinkuro, Inc.
> > >> _______________________________________________
> > >> Behave mailing list
> > >> [email-masked]
> > >> https://www.ietf.org/mailman/listinfo/behave
> > >>
> > >
> > > _______________________________________________
> > > Behave mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/behave
> > >
> > >
> >
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 2 Nov 2009 08:25:35 -0800

> From: Jacni Qin [mailto:[email-masked]] 
> Sent: Monday, November 02, 2009 7:26 AM
> To: Dan Wing
> Cc: marcelo bagnulo braun; Andrew Sullivan; [email-masked]
> i posted a draft to v6ops, draft-qin-v6ops-icp-transition-00, 
> which talks about using these protocols, just in one scenario 
> "the server side".

Thanks for the pointer.  I read draft-qin-v6ops-icp-transition-00 just now.  I
guess ICP = Internet Content Provider, and the draft is hoping to provide
guidance to them to handle incoming connections from dual-stack clients,
IPv6-only clients using a stateful NAT64, and IPv6-only clients using a
stateless NAT64 ("IVI").  Is that correct?  If so, I agree that such guidance
would be useful for both content sites that are remaining IPv4-only (and being
accessed via a NAT) as well as content sites that are supporting IPv6.  But
the document is pretty thin on specific recommendations right now; what sort
of recommendations do you feel are necessary for content providers?  

Such a recommendation document would be more useful if it also included
recommendations at layer 7 especially how HTTP and FTP need to function; for
example, HTTP needs to avoid IPv4 address literals, FTP servers need to
properly support EPSV.  The layer 7 recommendation document might be best done
in the IETF's application area, just due to how IETF is splintered into
different areas.  There is text related to internet content provider
recommendations currently scattered throughout several individual documents
that are associated with BEHAVE which could form a useful start to such a
document.

-d

---

From: Jacni Qin <[email-masked]>
Date: Tue, 3 Nov 2009 16:16:19 +0800

thanks for your time to read it,

Thanks for the pointer.  I read draft-qin-v6ops-icp-transition-00 just now.
>  I
> guess ICP = Internet Content Provider,

yes,

> and the draft is hoping to provide
> this -00 draft is just a start and needs much more text, :-)

maybe we didn't state it very clearly in the draft, actually it includes two
portions,
"the guidance to ISP" and "the guidance/request to ICP".

originally, weeks ago some ISPs told me that for some reasons, they were
considering
providing transition/migration solutions to their IDC customers (some ICPs
using their
IDC service), and they want to know how to do it, especially, how to use
these newly
developed transition tools(NAT64, IVI, ...). so we tried to document
something for them.

well, when the ISPs provide transition, they need to ask for the cooperation
of ICPs, as
some changes in the servers, system platforms are needed. so we also covered
some
requirements/guidance to ICPs. this part is what you mentioned above, i
guess.

-d

agree,
while for the recommendations at transport layer, such as how to use these
protocols
designed by Behave, maybe WG like v6ops is a right place. i do agree with
you about
the layer 7 things, but sometimes it is hard to discuss each separately. so,
make
one or two, and where? :-)

anyway, these kind of documents are needed, and on the other hand they are
helpful for
the development of protocols.

thanks,

Jacni

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 3 Nov 2009 09:54:50 +0100

On 2 nov 2009, at 17:25, Dan Wing wrote:

> But
> the document is pretty thin on specific recommendations right now;

Agree. I don't see how this document is useful, it just repeats stuff  
we already know except that it brings up IVI but not in enough detail  
to really learn anything.

I'm far from convinced that a document like this is needed, but if it  
is, it needs specific, useful recommendations. For instance, that IPv4  
networks don't use an MTU smaller than 1260.

Also note that repeating the same text (like the text from the  
abstract in the introduction) is very bad style.

Iljitsch

---

From: Jacni Qin <[email-masked]>
Date: Tue, 3 Nov 2009 19:38:39 +0800

thanks for your comments

while, as mentioned earlier, it is just a start to initiate a discussion on
whether we should document this kind of guidance,
as someone said in the thread, defining a protocol is different from using
it.

> I'm far from convinced that a document like this is needed, but if it is,
> it needs specific, useful recommendations. For instance, that IPv4 networks
> don't use an MTU smaller than 1260.
>
> Also note that repeating the same text (like the text from the abstract in
> the introduction) is very bad style.
>
> Iljitsch
>

ok, we can modify it to be not so bad to you. well, we are not as talented
as you that can produce a perfect 00 draft which needs
no further update any more.
joking, don't mind. ;-)

regards,

Jacni