Re: [BEHAVE] comments on draft-xu-behave-hybrid-type-prefix-00

> -----Original Message-----
> From: Xu Xiaohu [mailto:xuxh@huawei.com] 
> Sent: Monday, March 08, 2010 5:30 PM
> To: 'Dan Wing'; 'Cameron Byrne'
> Cc: draft-xu-behave-hybrid-type-prefix@tools.ietf.org; 'behave'
> Subject: re: [BEHAVE] comments on 
> draft-xu-behave-hybrid-type-prefix-00
> 
> 
> 
> > -----邮件原件-----
> > 发件人: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] 代表 Dan
> > Wing
> > 发送时间: 2010年3月9日 2:31
> > 收件人: 'Cameron Byrne'
> > 抄送: draft-xu-behave-hybrid-type-prefix@tools.ietf.org; 'behave'
> > 主题: Re: [BEHAVE] comments on draft-xu-behave-hybrid-type-prefix-00
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Cameron Byrne [mailto:cb.list6@gmail.com]
> > > Sent: Monday, March 08, 2010 10:13 AM
> > > To: Dan Wing
> > > Cc: behave; draft-xu-behave-hybrid-type-prefix@tools.ietf.org
> > > Subject: Re: [BEHAVE] comments on
> > > draft-xu-behave-hybrid-type-prefix-00
> > >
> > > On Mon, Mar 8, 2010 at 9:41 AM, Dan Wing <dwing@cisco.com> wrote:
> > > > Hi.  I just read draft-xu-behave-hybrid-type-prefix-00 and
> > > had some comments,
> > > >
> > > > * I am unclear on the motivation.  The content provider has
> > > deployed a NAT64
> > > > because the content provider was unable, or unwilling, to
> > > put native IPv6 on
> > > > the front-end server.  The content provider wants to create
> > > more work in the
> > > > IPv6 routing infrastructure (through the new 64::/16
> > > prefix) and RIRs so that
> > > > the NAT64 is used by IPv6-only devices and not used by
> > > dual-stack devices.
> > > >
> > > > * To be effective, I believe that this I-D requires the
> > > dual-stack clients to
> > > > modify their RFC3484 IPv6 address preferences to prefer
> > > IPv4 over 64::/16.
> > > > These dual-stack clients are on remote networks which
> > > aren't under the control
> > > > of the content provider (the content provider that has
> > > deployed the NAT64 and
> > > > is using the 64::/16 prefix).  But the I-D does not mention
> > > that requirement,
> > > > so perhaps I am misunderstanding.  Can this be clarified in
> > > email and in the
> > > > draft?
> > >
> > > Dan, what you are saying in the above point makes sense 
> to me and we
> > > can clarify the scenario in the in the I-D.
> > >
> > > The genesis of the ideas arose from this thread, where we 
> talk about
> > > weak and strong WKP as well as a network hosting many 
> NAT64 systems
> > > while having the beneficial properties of WKP -- where 
> the host knows
> > > it is communicating via a NAT64 translator.
> > >
> > > http://www.ietf.org/mail-archive/web/behave/current/msg07818.html
> > 
> > If I'm operating a bunch of dual-stack hosts, though, I may not
> > have an incentive to avoid the content provider's NAT64.
> > 
> > For example, the diagram in the I-D shows:
> > 
> >                        +-----------------+
> >                        |                 |
> >       +------------+   | IPv6 Internet   |  +-----+  +------------+
> >       | Dual-stack +---+                 +--+NAT64+--+ IPv4-only  |
> >       |            |   +-----------------+  +-----+  |            |
> >       |   +----+   |                                 |   +----+   |
> >       |   | H1 |   |   +-----------------+           |   | H2 |   |
> >       |   +----+   +---+                 +-----------+   +----+   |
> >       +------------+   | IPv4 Internet   |           +------------+
> >                        |                 |
> >                        +-----------------+
> > 
> > but let's imagine, instead, the network with the dual-stack
> > hosts is behind a NAPT44, as shown in this diagram:
> > 
> > 
> >                       +-------------+
> >                       |             |
> > +----------+          |IPv6 Internet| +-----+ +---------+
> > |Dual-stack+----------+             +-+NAT64+-+IPv4-only|
> > |          |          +-------------+ +-----+ |         |
> > |  +----+  |                                  |  +----+ |
> > |  | H1 |  | +------+ +-------------+         |  | H2 | |
> > |  +----+  +-+NAPT44+-+             +---------+  +----+ |
> > +----------+ +------+ |IPv4 Internet|         +---------+
> >                       |             |
> >                       +-------------+
> > 
> > Such a client network lacks an incentive to avoid the content
> > provider's NAT64.
> 
> Hi Dan,
> 
> The following is quoted from draft-wing-behave-dns64-config-02:
> 
>       Note:  If both a NAT44 and NAT64 are deployed on the 
> same network,
>       roughly the same inefficiency occurs (that is, NAT state is
>       created).  However, it is generally considered better to perform
>       NAT44 than NAT64, because NAT64 translates between IP address
>       families which can have side effects (e.g., FTP).
> 
> Does the quoted text make sense in the above scenario?

That quoted text refers to a different situation, when "both 
a NAT44 and NAT64 are deployed on the same network".  

If the case of draft-xu-behave-hybrid-type-prefix, they are
deployed on different networks:  the NAT44 is deployed in 
the network near the client, while the NAT64 is deployed in 
the network near the server.

I'm not seeing an incentive for the operator of network
on the left (with the dual-stack clients) to want to 
reconfigure their host's RFC3484 policy table to 
prioritize the 64::/16 prefix below native IPv4.

If you're saying the incentive is "some applications
will break", then that same problem exists for IPv6-only
clients, too.  And the content provider has the incentive
to fix their applications so they don't break.  If
the content provider does not fix their applications,
the content viewers will go elsewhere (and not view 
their advertising), or will abandon their IPv6 ISP 
and use IPv4.

-d

> Best wishes,
> Xiaohu
> 
> > -d
> > 
> > 
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
> 