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

[Jacni Qin <[e-mail]>]

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
> 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?
>
> 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.



> 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
>

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



>
>
> >
> > 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
> >
> >
> >
> >
>
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave
>