Subject: Re: [BEHAVE] Last Call: <draft-ietf-behave-v4v6-bih-06.txt> (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Sep 2011 16:28:58 +1200

Hi,

(Not copied to the IETF list, as it is an editorial point really. I'm
sorry I didn't see it before. Please view in Courier font.)

I have a little trouble with Figure 2:

      |  +------------------------------------------+ +---------+  |
      |  |    IPv4                                  | |         |  |
      |  +------------------------------------------+ | Address |  |
      |  +------------------+ +---------------------+ | Mapper  |  |
      |  |    Protocol      | |   Extension Name    | |         |  |
      |  |    Translator    | |   Resolver          | |         |  |
      |  +------------------+ +---------------------+ |         |  |
      |  +------------------------------------------+ |         |  |
      |  |    IPv4 / IPv6                           | |         |  |
      |  +------------------------------------------+ +---------+  |
      +------------------------------------------------------------+

        Figure 2: Architecture of a dual-stack host using protocol
                     translation at the network layer

The label "IPv4 / IPv6" is confusing. The only pathway we care
about is IPv4->translator/resolver->IPv6. I suppose IPv4 is shown
because this is *also* a dual stack node, but in that case you
should also show an optional direct IPv4 pathway. Something
like this:

      |  +------------------------------------------+ +---------+  |
      |  |    IPv4                                  | |         |  |
      |  +------------------------------------------+ | Address |  |
      |   | +-----------------+  +------------------+ | Mapper  |  |
      |   | |   Protocol      |  |   Extension Name | |         |  |
      |   | |   Translator    |  |   Resolver       | |         |  |
      |   | +-----------------+  +------------------+ |         |  |
      |   | +---------------------------------------+ |         |  |
      |   | |                 IPv6                  | |         |  |
      |   | +---------------------------------------+ +---------+  |
      +---V--------------------------------------------------------+

Regards
   Brian Carpenter

On 2011-09-01 01:53, The IESG wrote:
> The IESG has received a request from the Behavior Engineering for
> Hindrance Avoidance WG (behave) to consider the following document:
> - 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)'
>   <draft-ietf-behave-v4v6-bih-06.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2011-09-14. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol
>    translation mechanism that allows a class of IPv4-only applications
>    that work through NATs to communicate with IPv6-only peers.  The host
>    on which applications are running may be connected to IPv6-only or
>    dual-stack access networks.  BIH hides IPv6 and makes the IPv4-only
>    applications think they are talking with IPv4 peers by local
>    synthesis of IPv4 addresses.  This draft obsoletes RFC 2767 and RFC
>    3338.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Jiang Dong <[email-masked]>
Date: Thu, 8 Sep 2011 16:28:51 +0800

Hi，
	Are there any experiment drafts talking about  how CGN influence applications like p2p?
	Thak you for your kindly help if someone can give me a link.

	Best Regards!
	Jiang Dong

---

From: <[email-masked]>
Date: Thu, 8 Sep 2011 10:37:05 +0200

Dear Jiang,

We have done extensive testing with CGN (DS-Lite) implementations from various vendors to assess the behaviour of P2P applications (e.g., emule, Skype, Bittorent). The testing have been undertaken in two configuration (port forwarding activated vs. no port forwarding). We didn't published any report about all these validation testing.

BTW, we have published a detailed report about the behaviour of Bittorent in a shared environnemnt (the conclusion of that I-D applies for the CGN case also). The document is available at:

http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-address-sharing-00

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Jiang Dong
Envoyé : jeudi 8 septembre 2011 10:29
À : behave
Objet : [BEHAVE] Are there any experiment drafts talking about how CGN influence applications like p2p?

Hi，

        Best Regards!
        Jiang Dong

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 8 Sep 2011 09:12:14 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jiang Dong
> Sent: Thursday, September 08, 2011 1:29 AM
> To: behave
> Subject: [BEHAVE] Are there any experiment drafts talking about how CGN
> influence applications like p2p?
> 
> Hi，

What do you mean by "p2p".  Yes, I know it means "peer to peer", but
lots of things are peer to peer -- Octoshape, SIP, XMPP, Skype,
BitTorrent, approximately 49315 different Internet-enabled game
applications on various hardware platforms (XBox, PC, others).

-d

---

From: Jiang Dong <[email-masked]>
Date: Fri, 9 Sep 2011 10:37:50 +0800

Hi, Dan,
	 You are right. I'd like to find some drafts which describe how LSN influnence 
applications from the angle of function, performance and so on. The applications 
could be not only P2P, but also any others that may be influenced.
	 
	 draft-donley-nat444-impacts (Lee informed me, thaks a lot) is an useful one 
which described a variety of apps that would be influenced by NAT444. It seems 
not explain why these applications would be troubled...	

Best Regards!
Jiang Dong

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 9 Sep 2011 08:03:31 -0700

> Sent: Thursday, September 08, 2011 7:38 PM
> To: Dan Wing; 'behave'
> Subject: Re: [BEHAVE] Are there any experiment drafts talking about how
> CGN influence applications like p2p?
> 
> Hi, Dan,

draft-donley-nat444-impacts combines analysis of bandwidth constraint
(running over a cable plant) with in-home NAT with CGN.  Scientific
studies analyzing the effect of a treatment always have a "control
group" -- a group that does not receive the treatment, in order 
to judge the effect of the treatment.  draft-donley-nat444-impacts
does not have a control; that is, it did not perform the same exact
tests in the absence of the CGN, nor did it compare CGN-without-
in-home-NAT (which is the anticipated Dual Stack-Lite deployment).

I am hoping for a better analysis.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 9 Sep 2011 17:06:15 -0700

> From: Howard, Lee [mailto:[email-masked]]
> Sent: Friday, September 09, 2011 4:46 PM
> To: Dan Wing; 'Jiang Dong'; 'behave'
> Subject: RE: [BEHAVE] Are there any experiment drafts talking about how
> > >      draft-donley-nat444-impacts (Lee informed me, thaks a lot) is
> an
> > > useful one
> > > which described a variety of apps that would be influenced by
> NAT444.
> > > It seems
> That's true; in some cases it wasn't possible to tell why a given
> application
> was "troubled," and in other cases the authors simply did not have
> resources to investigate.   Many of them I think are well understood,
> though maybe not clearly described in the document.  For instance, p2p
> seeding is pretty clear; a seed behind a CGN contacts a tracker, which
> lists the inside address, which is an unreachable address from outside
> the CGN.

This occurs today with home NATs, too, if there isn't port forwarding 
on the NAT (e.g., UPnP IGD disabled on the NAT and manual port
forwarding isn't configured).  Fortunately, BitTorrent seeds can 
be asked to make outgoing connections.  So, all is not lost.  Things
are _better_ when incoming connections work, for sure.  

But of all the protocols on the Internet, I expect bittorrent 
applications and bittorrent users will be very able to accommodate 
most anything thrown in their way.  Same with Skype.

> Not entirely true; at least for the tests I ran, we first ran each test
> without a CGN, and then changed the routing to use the CGN.

Unfortunately that is not reflected in the text of 
draft-donley-nat444-impacts.

> Testing DS-Lite would be a different report.
> 
> I concede the document has significant limitations, and agree that more
> thorough description of why things failed would have been useful to
> the community.  I can't speak for all authors, but for myself, I simply
> did not have the resources to continue work, so the draft expired.
> For the issues I saw, I decided native dual-stack deployment would be
> easier than fixing the CGN issues, so that's where I have spent my
> time, money, and energy.

You are in the fortunate position to have sufficient IPv4 addresses
for your anticipated growth, so that you can defer IPv4 address
sharing until a future date.

-d

> Lee
> > > >> Subject: [BEHAVE] Are there any experiment drafts talking about
> how
> > > CGN
> > > >>  Are there any experiment drafts talking about  how CGN
> influence
> > > >> applications like p2p?
> > > >
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject
> to copyright belonging to Time Warner Cable. This E-mail is intended
> solely for the use of the individual or entity to which it is
> addressed. If you are not the intended recipient of this E-mail, you
> are hereby notified that any dissemination, distribution, copying, or
> action taken in relation to the contents of and attachments to this E-
> mail is strictly prohibited and may be unlawful. If you have received
> this E-mail in error, please notify the sender immediately and
> permanently delete the original and any copy of this E-mail and any
> printout.

---

From: "Howard, Lee" <[email-masked]>
Date: Fri, 9 Sep 2011 19:46:17 -0400

> > not explain why these applications would be troubled...

That's true; in some cases it wasn't possible to tell why a given application

easier than fixing the CGN issues, so that's where I have spent my time,
money, and energy.

Lee

> > >>  Thak you for your kindly help if someone can give me a link.

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 13 Sep 2011 12:50:59 +0900

The introduction in the draft says:

>   IETF recommends using dual-stack or tunneling based solutions for
>    IPv6 transition and specifically recommends against deployments
>    utilizing double protocol translation.  Use of BIH together with a
>    NAT64 is NOT RECOMMENDED [RFC6180].
> 

This statement makes a strong obstacle when we develop stateless solution with translation in softwires wg.
I think that it is still remained a room to make decision whether removing the statement or remaining it. 
The discussion which we'll have in the softwires interim meeting would be helpful to decide it.

Best regards,
--satoru

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 12 Sep 2011 20:56:17 -0700

> The discussion which we'll have in the softwires interim meeting would be
helpful to decide it.

+1

Nat464 has been shown to overcome real world issues, it solves a real
problem.

Additionally the bih mapper should not have to require DNS so that ipv4
literals can be overcome

Cb

> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf