[BEHAVE] draft-qin-v6ops-icp-transition [was RE: Using DNS64 to load balance to NAT64]

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: Jacni Qin [mailto:[e-mail]] 
> Sent: Monday, November 02, 2009 7:26 AM
> To: Dan Wing
> Cc: marcelo bagnulo braun; Andrew Sullivan; [e-mail]
> Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64
> 
> 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.

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



> 
> On Fri, Oct 23, 2009 at 10:45 PM, Dan Wing <[e-mail]> wrote:
> 
> 
> 
> 
> 	> -----Original Message-----
> 	> From: marcelo bagnulo braun [mailto:[e-mail]]
> 	> Sent: Friday, October 23, 2009 4:01 AM
> 	> To: Dan Wing
> 	> Cc: 'Andrew Sullivan'; [e-mail]
> 	> Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64
> 	>
> 	> Dan Wing escribió:
> 	> >
> 	> >
> 	> >
> 	> >> -----Original Message-----
> 	> >> From: [e-mail]
> 	> >> [mailto:[e-mail]] On Behalf Of 
> Andrew Sullivan
> 	> >> Sent: Thursday, October 22, 2009 10:56 AM
> 	> >> To: [e-mail]
> 	> >> 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
> 	> >> [e-mail]
> 	> >> Shinkuro, Inc.
> 	> >> _______________________________________________
> 	> >> Behave mailing list
> 	> >> [e-mail]
> 	> >> https://www.ietf.org/mailman/listinfo/behave
> 	> >>
> 	> >
> 	> > _______________________________________________
> 	> > Behave mailing list
> 	> > [e-mail]
> 	> > https://www.ietf.org/mailman/listinfo/behave
> 	> >
> 	> >
> 	>
> 	
> 	_______________________________________________
> 	Behave mailing list
> 	[e-mail]
> 	https://www.ietf.org/mailman/listinfo/behave
> 	
> 
> 
>