Ed Jankiewicz | 1 Nov 21:31 2010

Annotated Bibliography for IPv4-IPv6 Transition and coexistence

FYI

http://tools.ietf.org/html/draft-jankiewicz-v6ops-v4v6biblio-03

Nothing original here.  This draft is intended to be a common ground 
reference for the review and discussion of the RFCs, drafts and outside 
references around the topics of IPv6 transition and coexistence.  This 
is an open-ended task as the landscape keeps changing.   I hope it saves 
some folks some time finding all the same context.

The draft is on the v6ops agenda for a very brief presentation, to cover 
the background/motivation, solicit further contributions and to ask for 
opinions on the future disposition of the draft.  This could be a 
one-time individual/info publication, or form the basis for some 
evolving wiki on the subject.  There were several additions just before 
the -00 draft submission cutoff, so folks are still coming up with new 
ideas in the problem space.

Given that drafts on the subject are being developed in several working 
groups, I'm circulating this on several lists for general interest, 
comments and contributions.  Please do not reply-all and cross-post on 
the lists but rather e-mail me directly with any 
oversights/additions/deletions/corrections to citations, and especially 
if you would like to add any explanatory text.

thx
edj

Abstract:
The Internet is in the early stages of what may be a protracted
(Continue reading)

Hui Deng | 2 Nov 10:21 2010
Picon

Re: I-D Action:draft-ietf-behave-v4v6-bih-00.txt

Hello all
 
I would suggest to follow Jari's recommendation

"So please make sure that the draft focuses on the case where an IPv4-only application wants to contact an IPv6-only server, and put all other cases out of scope. Including "IPv6-only network"."

 

In this case, the text could be:

"Bump-In-the Host may be used when an IPv4-only application needs to communicate with a server the host can only reach via IPv6. Other cases are out of the scope of this document.

 

Jari also recommend

"Draft-arkko-ipv6-transition-guidelines has a little bit text about this, and I could add more, or we could develop an entirely new document about that topic."

We will contribute the text to Jari's draft or write a new document on this.

 
Hope everybody will be fine with this.
Best regards,
 
-Hui



2010/10/30 Jan Melen <jan.melen <at> nomadiclab.com>
Hi Teemu and Julien,

Sorry from my side that I have been tuned off from the discussion for a while...

On Oct 29, 2010, at 10:29 PM, Laganier, Julien wrote:

> teemu.savolainen <at> nokia.com wrote:
>>
>>> *  Bump-In-the-Host is to be used when an IPv4 application needs to
>>> *  communicate with an IPv6 server. Bump-In-the-Host SHOULD not be used
>>> *  network-side IP translation (e.g., NAT64) when the server has IPv4
>>> *  connectivity because it implies double translation.
>>
>> Julien, is the above text your propose one that from your point of view
>> covers this idea? I mean based on that, it is technically ok to use BIH
>> when the server is dual-stacked, if just the packet is not translated
>> again to IPv4, but transported as IPv6 to the server?
>>
>> From my point of view the mere existence of an IPv4 address on a dual-
>> stack server does not imply double translation - how could it? The BIH
>> host emits IPv6 packet with global source and destination addresses -
>> it does not even traverse through protocol translator.
>
> Hmm... Maybe I got confused. My only point is that I want this specification
> to recommend against combining the technology therein described with NAT64, as
> had been and still is being proposed outside the IETF.
>
> So about this:
>
> *  Bump-In-the-Host is to be used when an IPv4 application needs to
> *  communicate with an IPv6 server. Bump-In-the-Host SHOULD not be used
> *  together with network-side IP translation (e.g., NAT64.)
>
> ?

I agree with Julien that we need to be very clear on what we are recommending both for and against. Maybe this has not been the way we have worked earlier (personally I would disagree with that statement) but it is really what the outside world looks for. There is a real need for somebody to say that this thing X is good for this but if you use with this there will be problems. Certainly, there still will be people who will do anyhow against the recommendations but as majority still would like to be good citizens I think it is worthwhile giving them good guidance rather than opposite. So I'm in favor putting a clear statement as Julien suggests.

  Regards,
    Jan



<div>
<div>Hello all</div>
<div>&nbsp;</div>
<div>I would suggest to follow Jari's recommendation</div>
<div>
<p class="MsoPlainText"><span lang="EN-US">"So please make sure that the draft focuses on the case where an IPv4-only application wants to contact an IPv6-only server, and put all other cases out of scope. Including "IPv6-only network"."</span></p>

<p class="MsoPlainText"><span lang="EN-US"></span>&nbsp;</p>
<p class="MsoPlainText"><span lang="EN-US">In this case, the text could be:</span></p>
<p class="MsoPlainText"><span lang="EN-US">"<span lang="EN-US">Bump-In-the Host may be used when an IPv4-only application needs to communicate with a server the host can only reach via IPv6. Other cases are out of the scope of this document. </span>"&nbsp;</span></p>

<p class="MsoPlainText"><span lang="EN-US"></span>&nbsp;</p>
<p class="MsoPlainText"><span lang="EN-US">Jari also recommend</span></p>
<p class="MsoPlainText"><span lang="EN-US"><span lang="EN-US">"Draft-arkko-ipv6-transition-guidelines has a little bit text about this, and I could add more, or we could develop an entirely new document about that topic."</span></span></p>

<p class="MsoPlainText"><span lang="EN-US">We will contribute the text to Jari's draft or write a new document on this.</span></p>
<span lang="EN-US"></span>
</div>

<div>
<span lang="EN-US"></span>&nbsp;</div>
<div><span lang="EN-US">Hope everybody will be fine with this.</span></div>
<div><span lang="EN-US">Best regards,</span></div>
<div>
<span lang="EN-US"></span>&nbsp;</div>
<div><span lang="EN-US">-Hui</span></div>
<p class="MsoPlainText"><br><br></p>
<div class="gmail_quote">2010/10/30 Jan Melen <span dir="ltr">&lt;<a href="mailto:jan.melen <at> nomadiclab.com">jan.melen <at> nomadiclab.com</a>&gt;</span><br><blockquote class="gmail_quote">Hi Teemu and Julien,<br><br>Sorry from my side that I have been tuned off from the discussion for a while...<br><div class="im">
<br>On Oct 29, 2010, at 10:29 PM, Laganier, Julien wrote:<br><br>&gt; <a href="mailto:teemu.savolainen <at> nokia.com">teemu.savolainen <at> nokia.com</a> wrote:<br>&gt;&gt;<br>&gt;&gt;&gt; * &nbsp;Bump-In-the-Host is to be used when an IPv4 application needs to<br>
&gt;&gt;&gt; * &nbsp;communicate with an IPv6 server. Bump-In-the-Host SHOULD not be used<br>&gt;&gt;&gt; * &nbsp;network-side IP translation (e.g., NAT64) when the server has IPv4<br>&gt;&gt;&gt; * &nbsp;connectivity because it implies double translation.<br>
&gt;&gt;<br>&gt;&gt; Julien, is the above text your propose one that from your point of view<br>&gt;&gt; covers this idea? I mean based on that, it is technically ok to use BIH<br>&gt;&gt; when the server is dual-stacked, if just the packet is not translated<br>
&gt;&gt; again to IPv4, but transported as IPv6 to the server?<br>&gt;&gt;<br>&gt;&gt; From my point of view the mere existence of an IPv4 address on a dual-<br>&gt;&gt; stack server does not imply double translation - how could it? The BIH<br>
&gt;&gt; host emits IPv6 packet with global source and destination addresses -<br>&gt;&gt; it does not even traverse through protocol translator.<br>&gt;<br>&gt; Hmm... Maybe I got confused. My only point is that I want this specification<br>
&gt; to recommend against combining the technology therein described with NAT64, as<br>&gt; had been and still is being proposed outside the IETF.<br>&gt;<br>&gt; So about this:<br>&gt;<br>&gt; * &nbsp;Bump-In-the-Host is to be used when an IPv4 application needs to<br>
&gt; * &nbsp;communicate with an IPv6 server. Bump-In-the-Host SHOULD not be used<br>&gt; * &nbsp;together with network-side IP translation (e.g., NAT64.)<br>&gt;<br>&gt; ?<br><br>
</div>I agree with Julien that we need to be very clear on what we are recommending both for and against. Maybe this has not been the way we have worked earlier (personally I would disagree with that statement) but it is really what the outside world looks for. There is a real need for somebody to say that this thing X is good for this but if you use with this there will be problems. Certainly, there still will be people who will do anyhow against the recommendations but as majority still would like to be good citizens I think it is worthwhile giving them good guidance rather than opposite. So I'm in favor putting a clear statement as Julien suggests.<br><br>&nbsp; Regards,<br>&nbsp; &nbsp; Jan<br><br><br>
</blockquote>
</div>
<br>
</div>
Yong | 2 Nov 15:03 2010
Picon

Re: Annotated Bibliography for IPv4-IPv6 Transition andcoexistence

Good stuffs, Ed.

Just a comment: I think maybe you can also include the work on Softwire 
problem statement (i.e. RFC 4925) and Softwire Mesh, (e.g. RFC 5565 and 
so on).  
Additionally, you may also want to introduce the national-wide test bed, 
CNGI or CNGI-CERNET2.

Yong

======= 2010-11-02 04:31:17 You wrote =======

>FYI
>
>http://tools.ietf.org/html/draft-jankiewicz-v6ops-v4v6biblio-03
>
>Nothing original here.  This draft is intended to be a common ground 
>reference for the review and discussion of the RFCs, drafts and outside 
>references around the topics of IPv6 transition and coexistence.  This 
>is an open-ended task as the landscape keeps changing.   I hope it saves 
>some folks some time finding all the same context.
>
>The draft is on the v6ops agenda for a very brief presentation, to cover 
>the background/motivation, solicit further contributions and to ask for 
>opinions on the future disposition of the draft.  This could be a 
>one-time individual/info publication, or form the basis for some 
>evolving wiki on the subject.  There were several additions just before 
>the -00 draft submission cutoff, so folks are still coming up with new 
>ideas in the problem space.
>
>Given that drafts on the subject are being developed in several working 
>groups, I'm circulating this on several lists for general interest, 
>comments and contributions.  Please do not reply-all and cross-post on 
>the lists but rather e-mail me directly with any 
>oversights/additions/deletions/corrections to citations, and especially 
>if you would like to add any explanatory text.
>
>
>thx
>edj
>
>Abstract:
>The Internet is in the early stages of what may be a protracted
>period of coexistence of IPv4 and IPv6.  Network operators are
>challenged with the task of activating IPv6 without negative impact
>on operating IPv4 networks and their customers.  This draft is an
>informational "annotated bibliography" compiled to help in the
>analysis and development of basic guidelines and recommendations for
>network operators.  The goal of this document is to survey the
>current state of RFCs, Internet-Drafts and external reference
>materials that define the use cases, problem statements, protocols,
>transition mechanisms and coexistence tools that will be of interest
>to a network operator planning to turn on IPv6.
>
>
>
>
>
>_______________________________________________
>Softwires mailing list
>Softwires@...
>https://www.ietf.org/mailman/listinfo/softwires

=======================================

Best regards,
21:56:58 2010-11-02
********************************************************
*    Yong Cui                                          *
*    Ph.D, Department of Computer Science & Technology *
*    Tsinghua University, Beijing, P.R.China(100084)   *
*    Tel: (8610)-62603059                              *
*    Email: yong@...             *
********************************************************

Iljitsch van Beijnum | 3 Nov 19:41 2010

Re: review of draft-ietf-behave-ftp64-05

I'm currently working on an update of the draft, I'll finish this tomorrow. Here some responses to earlier
remarks in case anyone wants to disagree before then...

On 27 sep 2010, at 23:28, Dan Wing wrote:

>   document describes specifies a middlebox that may solve this
> ............^^^^^^^^^^^^^^^^^^^
>           remove duplicate wording

Check

>   necessary, clients and servers support EPSV successfully, such
> .................................^ 
>                                "to"

Check

> It seems useful to provide an Informational reference to the FTPEXT2 
> document at the end of the first sentence.

I did, and I removed the reference to the older liu draft.

>   go into transparent mode by issuing an AUTH or ALGS commands as
> .......................................^^
>                                 remove "an"

Check.

>      Where these words appear in lower case, they SHOULD NOT be	
> 	interpreted within the context of [RFC2119], but rather, in	
> 	accordance with regular English usage.

> I don't think that escape clause is useful.

Ok I'll remove it, but there are two lower case shoulds left in the document (and one in a reference):

Although these issues can and should be addressed by modifying, where necessary,

Should the IPv6 client issue an EPRT command

> Informational references:
> 
>   [Bernstein]
>              Bernstein, D., "PASV security and PORT security", 2000,
>              <http://cr.yp.to/ftp/security.html>.
> 
> is listed, but isn't referenced.  idnits complained about that.  IESG
> loves to run idnits, so we can't submit to IESG until that is fixed.

I'll see if there is a good place to refer to this or otherwise remove it.

>   that maps to the client's IPv6 address.  The port number must be
> ............................................................^^^^
>   preserved for compatibility with stateless translators.  For

> This should be an uppercase MUST; non-compliance with that sentence
> will break interoperability, right?

Right, made this upper case.

> Notwithstanding the escape clause in Notational Conventions,
> I see Section 12 (Timeouts and translating to NOOP) uses RFC2119
> language twice where it should really be uppercased:

We can have a discussion on whether it's useful to be able to use these terms in the normal non-2119 meaning,
but I uppercased them here.

> I poked around a little bit but I couldn't find a citation for those
> recommendations.  They both seem reasonable, but if there is a citation
> that would strengthen them.

I can't think of anything relevant that already exists that I can point to. 30 seconds seems long enough, 4
minutes like for normal TCP in a NAT seems too long. But the actual number isn't all that important, as long
as people know what to expect.

Iljitsch van Beijnum | 3 Nov 19:46 2010

Re: one week WGLC, draft-ietf-behave-ftp64-05

On 30 sep 2010, at 23:43, Dave Thaler wrote:

> The technical comment is that the text currently breaks internationalization as
> specified in RFC 2640 section 4, whereby the text part of responses can be
> UTF-8 non-English characters.  Currently several places in draft -05 either appear
> to specify the literal response (in English) or constrain the syntax to be ALPHA.
> In contrast RFC 2640 section 4 specifies %x01-%xFF instead of ALPHA.

I changed the ABNF to:

algs-command      = "ALGS" SP algs-token CRLF
algs-token        = "STATUS64" / "ENABLE64" / "DISABLE64" 

algs-response     = (ok-response / error-response) CRLF
ok-response       = "216" SP response-token [ freetext ]
response-token    = "NONE" / "EPSV" / "EPRT" / "EPSVEPRT"
error-response    = not-implemented / invalid-parameter
not-implemented   = "502" [ freetext ]
invalid-parameter = "504" [ freetext ]
freetext          = (SP *VCHAR)

So there should really only be three tokens now.

I didn't change the freetext specification for RFC 2640 compliance because I'm afraid this may break
certain clients and the ALG is not in a good position to negotiate language or UTF8 support. I added this text:

<xref target="RFC2640" /> specifies the ability for clients and servers to negotiate the language used
text messages between the two of them. This will typically involve the use of UTF-8 encoded characters
outside the 7-bit ASCII range. Because client compatibility with RFC 2640 is unknown, ALGs need adopt a
conservative position in this regard. As such, an ALG MUST NOT use any characters outside of the 7-bit
ASCII range in the text that it generates. However, an ALG MUST transparently forward commands and
responses containing UTF-8 encoded text when those occur.

Also:

In the sections that follow, a number of well-known response numbers are shown, along with the descriptive
text that is associated with that response number. However, the text is not part of the specification of
the response. As such, implementations MAY use the response text shown or they MAY show a different
response text for a given response number. Requirements language only applies to the response number.

You mention the framework draft where I talk about FTP servers elsewhere on the internet. I think I'll
reword to remove the explicit reference to the internet rather than to bring up the different scenarios
from the framework, because in my opinion, the latter would just confuse readers that aren't already
familiar with the framework document and require them to go out and read it, while there is really no need
for that.
Ala Hamarsheh | 3 Nov 23:23 2010
Picon

draft-hamarsheh-behave-biav2-03 VS draft-ietf-behave-v4v6-bih

Hi,

I highlight the differences between BIH (draft-ietf-behave-v4v6-bih) and our draft
(draft-hamarsheh-behave-biav2-03), we compared both, and a summary of conclusions is the following:

1. BIH is essentially an aggregation of the original BIA (RFC 3338) specification and the BIS (RFC 2767) specification.
The context in which BIH can be used is actually limited, to the following two situations:
- IPv4 only application communicating over IPv6 only network connectivity
- IPv4 only application communicating over IPv4/IPv6 dual network connectivity
The table below shows the scope in which BIH can be used:

            Host                                      Server
+---------------+-------------------+          +-------------------+
| Appl. Version | Host Connectivity | Network  | Host Connectivity |
+---------------+-------------------+          +-------------------+
|    IPv4       |      IPv6         | <-IPv6-≥ |      IPv6         |
+---------------+-------------------+          +-------------------+
|    IPv4       |       IPv6        | <-IPv6-≥ |    IPv4/IPv6      |
+---------------+-------------------+          +-------------------+

BIH uses IPv4 - IPv6 Network Address Translation when configured in the original BIA mode, or IPv4 - IPv6
protocol translation (with its associated overhead) when configured in the original BIS mode.
BIH is not aimed as a generic IPV6 transition tool.

2. Our draft is a generalization of the original BIA specification. It describes a mechanism for hosts with
IPv6 only, IPv4 only, or dual IPv6/IPv4 network connectivity to run IPv6 only, IPv4 only, or dual
IPv6/IPv4 applications without any modification to those applications. It allows complete decoupling
of application layer IPv4 or IPv6 operation from the underlying network layer IPv4 or IPv6 communication
being used, without requiring any modification in addressing capabilities to those applications,
effectively isolating the application layer from IPv6 or IPv4 connectivity. The table below shows the
scope in which the mechanism in our draft can be used:

            Source Host                          Destination Host
+---------------+-------------------+          +-------------------+
| Appl. Version | Host Connectivity | Network  | Host Connectivity |
+---------------+-------------------+          +-------------------+
|    IPv4       |      IPv6         | <-IPv6-≥ |      IPv6         |
+---------------+-------------------+          +-------------------+
|    IPv4       |      IPv6         | <-IPv6-≥ |    IPv4/IPv6      |
+---------------+-------------------+          +-------------------+
|    IPv6       |      IPv4         | <-IPv4-≥ |      IPv4         |
+---------------+-------------------+          +-------------------+
|    IPv6       |      IPv4         | <-IPv4-≥ |    IPv4/IPv6      |
+---------------+-------------------+          +-------------------+
|    IPv4       |    IPv4/IPv6      | <-IPv6-≥ |      IPv6         |
+---------------+-------------------+          +-------------------+
|    IPv6      |    IPv4/IPv6       | <-IPv4-≥ |      IPv4        |
+---------------+-------------------+          +-------------------+

Only IPv4 - IPv6 Network Address Translation is used, which implies minimal processing and communication overhead.
In contrast with BIH the mechanism proposed in our draft is intended as a generic tool to allow the
transition to IPv6 network operation without requiring all applications (both client and server side)
to be adapted to IPv6 capability.

SUMMARY: the mechanism proposed in our draft has a much wider intended scope compared to BIH.

Laganier, Julien | 4 Nov 03:53 2010

Re: I-D Action:draft-ietf-behave-v4v6-bih-00.txt

Hi,

Hui Deng wrote:
> Hello all
>  
> I would suggest to follow Jari's recommendation
> "So please make sure that the draft focuses on the case where an 
> IPv4-only application wants to contact an IPv6-only server, and put 
> all other cases out of scope. Including "IPv6-only network"."
>  
> In this case, the text could be:
> "Bump-In-the Host may be used when an IPv4-only application needs to
> communicate with a server the host can only reach via IPv6. Other
> cases are out of the scope of this document. " 
>  
> Jari also recommend
> "Draft-arkko-ipv6-transition-guidelines has a little bit text about
> this, and I could add more, or we could develop an entirely new 
> document about that topic."
> We will contribute the text to Jari's draft or write a new document on this.
>  
> Hope everybody will be fine with this.

As I said already, I'd like this specification to recommend against combining
the technology therein described with NAT64: 

  Bump-In-the-Host is to be used when an IPv4 application needs to
  communicate with an IPv6-only server. Bump-In-the-Host SHOULD not be used
  together with network-side IP translation (e.g., NAT64.) Other cases are
  out of the scope of this document.

--julien
Ikuhei.Yamagata | 4 Nov 09:46 2010
Picon

Re: Comments and question on scope of Re: I-D Action:draft-ietf-behave-lsn-requirements-00.txt

Hi, Reinaldo

Thank you for your comment and sorry for our is delay...

Comments inline...

On Wed, 20 Oct 2010 12:09:09 -0400
Reinaldo Penno <rpenno <at> juniper.net> wrote:

> Hello Dan,
> 
> Comments inline...
> 
> 
> On 10/20/10 8:57 AM, "Dan Wing" <dwing <at> cisco.com> wrote:
> 
> >> -----Original Message-----
> >> From: Reinaldo Penno [mailto:rpenno <at> juniper.net]
> >> Sent: Wednesday, October 20, 2010 3:35 AM
> >> To: Ikuhei.Yamagata; behave <at> ietf.org; Dave Thaler
> >> Cc: shared <at> hir.jp; Dan Wing
> >> Subject: Comments and question on scope of Re: [BEHAVE] I-D
> >> Action:draft-ietf-behave-lsn-requirements-00.txt
> >> 
> >> Hello
> >> 
> >> I think this document is a good start but needs some work as WG
> >> document.
> >> 
> >> First and foremost a question to chairs/WG: does this document apply
> >> only to NAT44(4) or NAT64 and DS-Lite as well?
> > 
> > Anytime there is a "large" NAT.  So all of those you listed, and
> > probably other architectures as well.
> 
> Thanks for the clarification.
> 
> > 
> >> NAT64 and DS-Lite also use/are 'LSN' and if this is the case the
> >> document needs more text to cater to those scenarios.
> >> 
> >> Comments to this document.
> >> 
> >> 1 -
> >> 
> >> Some of the original CGN requirements document used to just copy &
> >> paste
> >> requirements from RFC4787, RFC5382 and RFC5508.
> >> 
> >> I'm glad to see most of that text was removed since it was repetitive
> >> but
> >> the draft still mentions that "However so, because those RFCs are
> >> mainly
> >> aimed at residential CPE
> >>    and any IPv4 address sharing schemes are a bit different from it, we
> >>    believe that requirements for LSN and other schemes should be
> >> defined
> >>    alternatively to those RFCs."
> >> 
> >> But I do not see any requirements that are alternative/opposed to the
> >> original RFCs. Only a few new things. Sections 4 and 5 seem to have
> >> nothing
> >> different from the original RFCs - or maybe it is my interpretation.
> >> 

Sections 3 and 4 have a few new things, but it maybe hard to find.

> >> Is it possible to flag more descriptively which requirements in the
> >> draft are alternative/opposed from RFC4787, RFC5382 and RFC5508?
> > 
> > I agree the document should be clearer when it is re-stating a
> > requirement or when it is changing an existing requirement.  I have
> > suggested changes to the document authors (as an individual) but
> > those suggestions have not been integrated.
OK. We try to write more clear about it.

> > 
> >> 2 -
> >> 
> >> The requirements for translation log differ across different countries,
> >> law
> >> enforcement and others. Therefore section 7.1 can not be applied to all
> >> LSNs. Certain ISPs are not so interested in destination IP address and
> >> port and can use port ranges for users (see below)
> > 
> > There are three documents (that I'm aware of) which discuss logging
> > to different degrees:
> > 
> >   draft-ietf-behave-lsn-requirements
> >   draft-ietf-intarea-shared-addressing-issues
> >   draft-durand-server-logging-recommendations
> > 
> > We should decide where that text needs to live, and what that text
> > needs to say.  
We think so, and our thought is similar to draft-ietf-intarea-shared-addressing-issues.
If servers log source port number like draft-durand-server-logging-recommendations, LSNs are not need
to log destination address.

> > 
> > 
> >> 3 -
> >> 
> >> Section 7.2 text is somewhat confusing when states that
> >> 
> >> " Note that
> >>    this mechanism is possible only if the source port is known as well
> >>    as the source address, the destination address and the destination
> >>    port."
> >> 
> >> Maybe I'm missing something but how the destination address will be
> >> known in
> >> advance? There are millions websites in the world and you can not know
> >> which
> >> one the subscriber will access at any given point in time.
> >> 
> >> My suggestion is to reword as
> >> 
> >> " Note that
> >>    this mechanism is possible only if logging the destination IP and
> >> port by
> >> the LSN is not necessary"
> >> 
> >> See the discussion in
> >> http://tools.ietf.org/html/draft-tsou-behave-natx4-log-reduction-02
> >> 
This means "If servers log not only source address but also source port, 
this mechanism is possible".

This means servers are need to know(log) source port, source address, destination address(server's IP
address) and 
destination port(e.x http is tcp 80) if LSN use this mechanism.

> >> 4- -
> >> 
> >> I could not follow this requirement. Could you elaborate?
> >> 
> >> "     b) A LSN MAY reuse LSN external port while the port is allocated
> >>       for no session originated by any CPE."
> >> 
Yes, we write on purpose. But it may be incomprehensible...

This example...
userA gets LSN's port range in advance.(IPaddress:100.0.0.1 port number:1024-2048)
userB trys to connect with same LSN, but there is not enough address:port.
In this case, userB can use ports which gotten and not used by a userA.

But, I am afraid of misunderstanding, so we think to change like this.
b) A LSN MUST NOT use LSN external port allocated and used by any CPE.

> >> 5 -
> >> 
> >> Why the two requirements below are a 'SHOULD'?
> >> 
> >> "      c) A LSN SHOULD limit the number of the LSN external ports of
> >> TCP
> >>       per CPE.
> >> 
> >>       e) A LSN SHOULD limit the number of the new sessions of TCP per
> >>       time unit and per CPE."
> >> 
> >> In some ISPs the ratio of available ports to subscriber (compression)
> >> is
> >> very low and those mechanisms are not needed at all.
> > 
> > Disagree.  Without such a limit, a malfunctioning host or a host
> > doing port scanning could consume all 64K ports, causing a DoS for
> > other users behind that same NAT, without consuming much bandwidth
> > at all.
> 
> Exactly, some people agree others do not. This is a deployment decision. We
> provide a knob and let ISPs decide.
> 
> > 
> >> This varies
> >> considerably across deployments.
> >> 
> >> I suggest to reword this as ..."the LSN MAY allow the number of
> >> external TCP
> >> ports and sessions per second per subscriber to be configured"
> > 
> > I believe the requirement is that a large scale NAT provide a 'knob'
> > to allow the LSN operator to set the value.
> 
> Yes. 
We think so, too.
And we think many ISP use port limitation function.
So, we think "SHOULD" is comfortable.

> 
> > 
> > 
> >> 6 -
> >> 
> >> The text below seems somewhat ambiguous
> >> 
> >> "  Justification: Some specific applications don't work well due to
> >>    limitation of number of number of ports by LSN, therefore other
> >>    applications might be affected in the same CPE."
> >> 
> >> All application will be affected by limiting the number of ports if all
> >> ports were consumed. It is just a function of time and how many ports
> >> have
> >> been consumed not the application per se.
> >> 
Yes.
Some application may deadlock because application cannot connect DNS server (for limiting connection).
We are afraid of this, so we think this function.
But we don't know there is applications like this, so we write "MAY".

> >> 7 -
> >> 
> >> In section 10 I'm not sure what is the requirement exactly. Can you
> >> give an
> >> example on how preventing spoofing can be achieved in NAT444
> >> deployments as
> >> opposed to, say, DS-Lite. A subscriber can spoof the 3-tuple unless
> >> that is
> >> prevented on the CPE itself.
> > 
> > In NAT444, ingress filtering works just like it does today:  the
> > source address of traffic from the subscriber can be filtered to
> > only be the IP address assigned by DHCP (or PPP).
> 
> 
> I think there is a disconnect. If the LSN is deep into the network, how it
> will perform ingress filtering for DHCP subs? How will it know that packets
> from source IP 10.0.0.2 are coming from CPE B instead of CPE C, or D?
> 
> PPP is okay, I understand this scenario.
> Unless each subscriber is routed to a different interface/VLAN, also
> understand this scenario.
> 
> 
> > 
> >> Or maybe it is not a spoof and just that IP address was reassigned and
> >> still
> >> many TCP sessions lingering on the LSN preventing new subscriber from
> >> establishing sessions.
> > 
> > IPv4 address re-assignment happens today, on today's Internet, with
> > some ISPs.  ISPs do that to thwart subscribers running servers.  Those
> > same ISPs will have fewer reasons to re-assign the subscriber IP address
> > when the subscriber is behind a LSN.
> > 
> > -d
> > 
> > 
> >> Thanks,
> >> 
> >> Reinaldo
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> On 10/19/10 6:18 PM, "Ikuhei.Yamagata" <ikuhei <at> nttv6.jp> wrote:
> >> 
> >>> Dear all,
> >>> 
> >>> We posted new behave WG, draft-ietf-behave-lsn-requirements.
> >>> This draft changed from draft-nishitani-cgn, and some requirements
> >> changes.
> >>> 
> >>> Comments most welcomed!
> >>> 
> >>> Best wishes,
> >>> ikuhei
> >>> 
> >>> On Mon, 18 Oct 2010 02:30:09 -0700 (PDT)
> >>> Internet-Drafts <at> ietf.org wrote:
> >>> 
> >>>> A New Internet-Draft is available from the on-line Internet-Drafts
> >>>> directories.
> >>>> This draft is a work item of the Behavior Engineering for Hindrance
> >> Avoidance
> >>>> Working Group of the IETF.
> >>>> 
> >>>> 
> >>>> Title           : Common requirements for IP address sharing schemes
> >>>> Author(s)       : I. Yamagata, et al.
> >>>> Filename        : draft-ietf-behave-lsn-requirements-00.txt
> >>>> Pages           : 13
> >>>> Date            : 2010-10-18
> >>>> 
> >>>> This document defines common requirements of multiple types of Large
> >>>> Scale Network Address Translation (NAT) that handles Unicast UDP,
> >> TCP
> >>>> and ICMP.
> >>>> 
> >>>> A URL for this Internet-Draft is:
> >>>> http://www.ietf.org/internet-drafts/draft-ietf-behave-lsn-
> >> requirements-00.txt
> >>>> 
> >>>> Internet-Drafts are also available by anonymous FTP at:
> >>>> ftp://ftp.ietf.org/internet-drafts/
> >>>> 
> >>>> Below is the data which will enable a MIME compliant mail reader
> >>>> implementation to automatically retrieve the ASCII version of the
> >>>> Internet-Draft.
> >>> 
> >>> ----------------------------------------------
> >>> Ikuhei Yamagata
> >>> Innovative IP Architecture Center
> >>> NTT Communications Corporation
> >>> ikuhei <at> nttv6.jp
> >>> phone:81-3-6733-8671(main)
> >>>             50-3812-4704(direct)
> >>> ----------------------------------------------
> >>> 
> >>> _______________________________________________
> >>> Behave mailing list
> >>> Behave <at> ietf.org
> >>> https://www.ietf.org/mailman/listinfo/behave
> > 
> 
> _______________________________________________
> Behave mailing list
> Behave <at> ietf.org
> https://www.ietf.org/mailman/listinfo/behave

----------------------------------------------
Ikuhei Yamagata
Innovative IP Architecture Center
NTT Communications Corporation
ikuhei <at> nttv6.jp
phone:81-3-6733-8671(main)
            50-3812-4704(direct)
----------------------------------------------

teemu.savolainen | 4 Nov 10:27 2010
Picon

Re: draft-hamarsheh-behave-biav2-03 VS draft-ietf-behave-v4v6-bih

Hi,

If you check out one of the predecessor of current bih draft, e.g.
http://tools.ietf.org/id/draft-huang-behave-rfc3338bis-00.txt , you will see familiar looking
figure 2. Also in the Introduction it is, for example, stated that:
--
   If the network which host is connecting with is IPv4 only network,
   then host's IPv4 application will behave regularly, and it's IPv6
   application's packets have to be translated into IPv4 packets.
--

Since those early versions of BIAbis the draft's purpose been narrowed down to cover only the use case
behave WG is chartered to work on. Hence your generic draft has too wide scope when considering the goals of
behave wg (IETF does *not* want generic host based protocol translation tool for IPv6 transition).

Best regards,

Teemu

> -----Original Message-----
> From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On
> Behalf Of ext Ala Hamarsheh
> Sent: 04. marraskuuta 2010 00:23
> To: behave <at> ietf.org
> Subject: [BEHAVE] draft-hamarsheh-behave-biav2-03 VS draft-ietf-behave-
> v4v6-bih
> 
> Hi,
> 
> I highlight the differences between BIH (draft-ietf-behave-v4v6-bih)
> and our draft (draft-hamarsheh-behave-biav2-03), we compared both, and
> a summary of conclusions is the following:
> 
> 1. BIH is essentially an aggregation of the original BIA (RFC 3338)
> specification and the BIS (RFC 2767) specification.
> The context in which BIH can be used is actually limited, to the
> following two situations:
> - IPv4 only application communicating over IPv6 only network
> connectivity
> - IPv4 only application communicating over IPv4/IPv6 dual network
> connectivity
> The table below shows the scope in which BIH can be used:
> 
>             Host                                      Server
> +---------------+-------------------+          +-------------------+
> | Appl. Version | Host Connectivity | Network  | Host Connectivity |
> +---------------+-------------------+          +-------------------+
> |    IPv4       |      IPv6         | <-IPv6-≥ |      IPv6         |
> +---------------+-------------------+          +-------------------+
> |    IPv4       |       IPv6        | <-IPv6-≥ |    IPv4/IPv6      |
> +---------------+-------------------+          +-------------------+
> 
> BIH uses IPv4 - IPv6 Network Address Translation when configured in the
> original BIA mode, or IPv4 - IPv6 protocol translation (with its
> associated overhead) when configured in the original BIS mode.
> BIH is not aimed as a generic IPV6 transition tool.
> 
> 2. Our draft is a generalization of the original BIA specification. It
> describes a mechanism for hosts with IPv6 only, IPv4 only, or dual
> IPv6/IPv4 network connectivity to run IPv6 only, IPv4 only, or dual
> IPv6/IPv4 applications without any modification to those applications.
> It allows complete decoupling of application layer IPv4 or IPv6
> operation from the underlying network layer IPv4 or IPv6 communication
> being used, without requiring any modification in addressing
> capabilities to those applications, effectively isolating the
> application layer from IPv6 or IPv4 connectivity. The table below shows
> the scope in which the mechanism in our draft can be used:
> 
>             Source Host                          Destination Host
> +---------------+-------------------+          +-------------------+
> | Appl. Version | Host Connectivity | Network  | Host Connectivity |
> +---------------+-------------------+          +-------------------+
> |    IPv4       |      IPv6         | <-IPv6-≥ |      IPv6         |
> +---------------+-------------------+          +-------------------+
> |    IPv4       |      IPv6         | <-IPv6-≥ |    IPv4/IPv6      |
> +---------------+-------------------+          +-------------------+
> |    IPv6       |      IPv4         | <-IPv4-≥ |      IPv4         |
> +---------------+-------------------+          +-------------------+
> |    IPv6       |      IPv4         | <-IPv4-≥ |    IPv4/IPv6      |
> +---------------+-------------------+          +-------------------+
> |    IPv4       |    IPv4/IPv6      | <-IPv6-≥ |      IPv6         |
> +---------------+-------------------+          +-------------------+
> |    IPv6      |    IPv4/IPv6       | <-IPv4-≥ |      IPv4        |
> +---------------+-------------------+          +-------------------+
> 
> Only IPv4 - IPv6 Network Address Translation is used, which implies
> minimal processing and communication overhead.
> In contrast with BIH the mechanism proposed in our draft is intended as
> a generic tool to allow the transition to IPv6 network operation
> without requiring all applications (both client and server side) to be
> adapted to IPv6 capability.
> 
> SUMMARY: the mechanism proposed in our draft has a much wider intended
> scope compared to BIH.
> 
> _______________________________________________
> Behave mailing list
> Behave <at> ietf.org
> https://www.ietf.org/mailman/listinfo/behave
teemu.savolainen | 4 Nov 13:18 2010
Picon

Re: draft-hamarsheh-behave-biav2-03 VS draft-ietf-behave-v4v6-bih

Hi,

 

The IETF’s approach for the generic problem of supporting IPv4-only apps (connecting to IPv4-only servers) is dual-stack or tunneling, e.g. IPv4 packets encapsulated in IPv6 (see DS-Lite for example).

 

Have you considered adding considerations for applications that embed IP addresses in protocol payloads (i.e. for ALG considerations)?

 

I would like to encourage you to review and comment on BIH in behave WG’s scope. I mean could you see BIH as a subset of what you aim at, i.e. helping also you to achieve your goals? You could then maybe focus your draft to extend BIH?

 

In the future we will see IPv6-only applications for sure, but for time being I’m personally not too convinced there will soon be IPv6-only applications that are also happy working through NAT64 (those apps would not work in IPv4-only accessesJ. Instead I expect IPv6-only applications that really require peers to be on IPv6 as well and dual-stack applications that also work in IPv4-only accesses.

 

One comment to previous mail. I think the BIH capability table you sent should have third row (added):

            Host                                      Server

+---------------+-------------------+          +-------------------+

| Appl. Version | Host Connectivity | Network  | Host Connectivity |

+---------------+-------------------+          +-------------------+

|    IPv4       |      IPv6         | <-IPv6-> |      IPv6         |

+---------------+-------------------+          +-------------------+

|    IPv4       |      IPv6         | <-IPv6-> |    IPv4/IPv6      |

+---------------+-------------------+          +-------------------+

|    IPv4       |    IPv4/IPv6      | <-IPv6-> |      IPv6         |

+---------------+-------------------+          +-------------------+

 

 

Best regards,

 

Teemu

 

From: ext Goossens, Marnix [mailto:magoosse <at> etro.vub.ac.be]
Sent: 04. marraskuuta 2010 13:47
To: Savolainen Teemu (Nokia-MS/Tampere)
Cc: ,; behave <at> ietf.org
Subject: Re: [BEHAVE] draft-hamarsheh-behave-biav2-03 VS draft-ietf-behave-v4v6-bih

 

 

Hello Teemu

 

>Since those early versions of BIAbis the draft's purpose been narrowed down to cover only the use case behave WG is chartered to work on. Hence your generic draft has too wide scope when considering the goals >of behave wg (IETF does *not* want generic host based protocol translation tool for IPv6 transition).

 

I am sending you below part of the motivation in the draft why we propose a generic tool, and why we think wide-spread deployment of IPv6, especially in residential context, is bound to fail if not something drastic is done about allowing IPv4-only applications to communicate transparantly over IPv6. I have been fighting for years (mainly in Europe) the blindness of IETF towards PRAGMATIC issues, the IETF  sometimes taking a rather "idealistic" (but naive) technical-only stance towards issues such as multicast and now IPv6, and the focus of IETF on network operations mostly ignoring in the process the end-user's viewpoint.

If you care to read the motivation, you will find that it is not at all about technical problems, but human and commercial issues...

 

It may be that we have send the draft in error to the behave group, if that WG is too narrow in scope, but we probably had little choice...

 

Kind regards,

 

Marnix Goossens

 

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

It is probably important to give a brief analysis first of one of the
blocking factors withholding the wide-spread introduction of IPv6 in
order to fully understand why the here proposed BIA is considered an
essential component in the unlocking of IPv6.
At the inception of IPv6 it was - probably rather naively - presumed that all
parties involved with the Internet would be eager to make the
changeover and that the transition would happen spontaneously.
It is now quite generally acknowledged that some human and commercial
factors preventing a spontaneous transition have been largely
underestimated. In the transition to IPv6 there are essentially
two parties involved: network providers and end-users.
The benefits of using IPv6 are almost entirely for the network
providers, while the end-users have only potentially indirect
benefits from better network operation. No drive to make the
changeover should be expected from the majority of end-users

(which includes application developers, that are working for these end-users),
as they have probably little to gain. The network providers can expect
benefits, but they are obviously dependent on the willingness of their
end-users to make any changeover. The result is some kind of
deadlock: no (commercial) network provider is going to force the
customers to make the changeover against their will. So making the
transition transparent to the end-user is the key in any transition
to IPv6. The average end-users are not really aware about what goes on
in the network layer, and even if they do, they usually could not care
less. It does not matter much to them if their applications are
communicating using IPv4 or IPv6. But, while there is no drive to be
expected from the end-users for any transition to IPv6, the vast
majority would not object to the transition on condition they can go
on using their applications as before.
While the first impression is that applications are not affected
by the changeover on the IP layer from IPv4 to IPv6, this is
unfortunately not true. The applications are using IP addresses,
and hence should be capable of dealing with the longer IPv6 addresses
when having to communicate over IPv6.
Expecting all applications to be modified to be capable of dealing
with the longer IPv6 addresses is rather naive. Apart from the
"standard" Internet applications with rather good support such as
web browsers, email programs, etc. that can be expected to be IPv6
enabled, there are thousands of other applications, some of them are
written by small companies (of which some may be out of business)
and others are even "home-made". For some applications, Internet
communication is only a side-issue, for example for registering
and/or checking for updates, and upgrading to become IPv6 compatible
is probably not a high priority. It is to be expected that a large
proportion of applications will only be modified to be IPv6
compatible when IPv6 usage gets into full swing. And even if the
IPv6 capable new versions of application software are made available,
it is again rather naive to expect all end-users to do the required
updating of all the software on their system.
The end-users MAY be willing to accept a changeover to IPv6, but will
NOT accept that some of their applications will no longer work as
before. From this observation it becomes obvious that it is
absolutely essential that provisions are standard installed and
enabled on any general purpose machine (the vast majority of systems
connected to the Internet) that is provided for IPv6 communication
and potentially has to run IPv4-only applications to continue
communicating as before when communicating using IPv6. While the
demand for mandatory provisions on every general purpose machine
capable of communicating using IPv6 may seem a tall order,
it should be realized that this approach is much more realistic
then expecting ALL applications to be made IPv6 compatible:
compared to thousands of applications that would need conversion
requiring all application developers to follow suit, the number of
communication stack implementations on general purpose machines is
very small and is made by only a handful of developers.

<div>

<div class="WordSection1">

<p class="MsoNormal"><span>Hi,<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>The IETF&rsquo;s approach for the generic problem of supporting
IPv4-only apps (connecting to IPv4-only servers) is dual-stack or tunneling,
e.g. IPv4 packets encapsulated in IPv6 (see DS-Lite for example). <p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>Have you considered adding considerations for applications that
embed IP addresses in protocol payloads (i.e. for ALG considerations)?<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>I would like to encourage you to review and comment on BIH in
behave WG&rsquo;s scope. I mean could you see BIH as a subset of what you aim at,
i.e. helping also you to achieve your goals? You could then maybe focus your draft
to extend BIH?<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>In the future we will see IPv6-only applications for sure, but
for time being I&rsquo;m personally not too convinced there will soon be
IPv6-only applications that are also happy working through NAT64 (those apps
would not work in IPv4-only accesses</span><span>J</span><span>. Instead I expect IPv6-only
applications that really require peers to be on IPv6 as well and dual-stack
applications that also work in IPv4-only accesses. <p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>One comment to previous mail. I think the BIH capability table you
sent should have third row (added):<p></p></span></p>

<p class="MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Host&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Server<p></p></p>

<p class="MsoPlainText">+---------------+-------------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-------------------+<p></p></p>

<p class="MsoPlainText">| Appl. Version | Host Connectivity | Network&nbsp; |
Host Connectivity |<p></p></p>

<p class="MsoPlainText">+---------------+-------------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-------------------+<p></p></p>

<p class="MsoPlainText">|&nbsp;&nbsp;&nbsp;
IPv4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IPv6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | &lt;-IPv6-&gt;
|&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;IPv6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<p></p></p>

<p class="MsoPlainText">+---------------+-------------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-------------------+<p></p></p>

<p class="MsoPlainText">|&nbsp;&nbsp;&nbsp;
IPv4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;IPv6 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|
&lt;-IPv6-&gt; |&nbsp;&nbsp;&nbsp; IPv4/IPv6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<p></p></p>

<p class="MsoPlainText">+---------------+-------------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-------------------+<p></p></p>

<p class="MsoPlainText">|&nbsp;&nbsp;&nbsp;
IPv4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; &nbsp;IPv4/IPv6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| &lt;-IPv6-&gt; |&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;IPv6&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<p></p></p>

<p class="MsoPlainText">+---------------+-------------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-------------------+<p></p></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>Best regards,<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>Teemu<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<div>

<div>

<div>

<p class="MsoNormal"><span>From:</span><span> ext Goossens,
Marnix [mailto:magoosse <at> etro.vub.ac.be] <br>Sent: 04. marraskuuta 2010 13:47<br>To: Savolainen Teemu (Nokia-MS/Tampere)<br>Cc: ,; behave <at> ietf.org<br>Subject: Re: [BEHAVE] draft-hamarsheh-behave-biav2-03 VS
draft-ietf-behave-v4v6-bih<p></p></span></p>

</div>

</div>

<p class="MsoNormal"><p>&nbsp;</p></p>

<div>

<p><span>&nbsp;<p></p></span></p>

<p><span>Hello
Teemu<p></p></span></p>

<p><span>&nbsp;<p></p></span></p>

<p><span>&gt;Since
those early versions of BIAbis the draft's purpose been narrowed down to cover
only the use case behave WG is chartered to work on. Hence your generic draft
has too wide scope when considering the goals &gt;of behave wg (IETF does *not*
want generic host based protocol translation tool for IPv6 transition).<p></p></span></p>

<p><span>&nbsp;<p></p></span></p>

<p><span>I
am sending you below part of the motivation in the draft why we&nbsp;propose a
generic tool, and why we think wide-spread deployment of IPv6, especially in
residential context, is bound to fail if not something drastic is done about
allowing IPv4-only applications to communicate transparantly over IPv6. I have
been fighting for years (mainly in Europe) the blindness of IETF towards
PRAGMATIC issues, the IETF&nbsp; sometimes taking a rather
"idealistic" (but naive) technical-only&nbsp;stance towards issues
such as multicast and now IPv6, and the focus of IETF on network operations
mostly ignoring in the process the end-user's viewpoint.<p></p></span></p>

<p><span>If
you care to read the motivation, you will find that it is not at all about
technical problems, but human and commercial issues...<p></p></span></p>

<p><span>&nbsp;<p></p></span></p>

<p><span>It
may be that we have send the draft in error to the behave group, if that WG is
too narrow in scope, but we probably had little choice...<p></p></span></p>

<p><span>&nbsp;<p></p></span></p>

<p><span>Kind
regards,<p></p></span></p>

<p><span>&nbsp;<p></p></span></p>

<p><span>Marnix
Goossens<p></p></span></p>

<p><span>&nbsp;<p></p></span></p>

<p><span>----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br><br>
It is probably important to give a brief analysis first of one of the<br>
blocking factors withholding the wide-spread introduction of IPv6 in<br>
order to fully understand why the here proposed BIA is considered an<br>
essential component in the unlocking of IPv6.<br>
At the inception of IPv6 it was - probably rather naively - presumed that all<br>
parties involved with the Internet would be eager to make the<br>
changeover and that the transition would happen spontaneously.<br>
It is now quite generally acknowledged that some human and commercial<br>
factors preventing a spontaneous transition have been largely<br>
underestimated. In the transition to IPv6 there are essentially<br>
two parties involved: network providers and end-users.<br>
The benefits of using IPv6 are almost entirely for the network<br>
providers, while the end-users have only potentially indirect<br>
benefits from better network operation. No drive to make the<br>
changeover should be expected from the majority of end-users<p></p></span></p>

<p><span>(which
includes application developers, that are working for these end-users),<br>
as they have probably little to gain. The network providers can expect<br>
benefits, but they are obviously dependent on the willingness of their<br>
end-users to make any changeover. The result is some kind of<br>
deadlock: no (commercial) network provider is going to force the<br>
customers to make the changeover against their will. So making the<br>
transition transparent to the end-user is the key in any transition<br>
to IPv6. The average end-users are not really aware about what goes on<br>
in the network layer, and even if they do, they usually could not care<br>
less. It does not matter much to them if their applications are<br>
communicating using IPv4 or IPv6. But, while there is no drive to be<br>
expected from the end-users for any transition to IPv6, the vast<br>
majority would not object to the transition on condition they can go<br>
on using their applications as before.<br>
While the first impression is that applications are not affected<br>
by the changeover on the IP layer from IPv4 to IPv6, this is<br>
unfortunately not true. The applications are using IP addresses,<br>
and hence should be capable of dealing with the longer IPv6 addresses<br>
when having to communicate over IPv6.<br>
Expecting all applications to be modified to be capable of dealing<br>
with the longer IPv6 addresses is rather naive. Apart from the<br>
"standard" Internet applications with rather good support such as<br>
web browsers, email programs, etc. that can be expected to be IPv6<br>
enabled, there are thousands of other applications, some of them are<br>
written by small companies (of which some may be out of business)<br>
and others are even "home-made". For some applications, Internet<br>
communication is only a side-issue, for example for registering<br>
and/or checking for updates, and upgrading to become IPv6 compatible<br>
is probably not a high priority. It is to be expected that a large<br>
proportion of applications will only be modified to be IPv6<br>
compatible when IPv6 usage gets into full swing. And even if the<br>
IPv6 capable new versions of application software are made available,<br>
it is again rather naive to expect all end-users to do the required<br>
updating of all the software on their system.<br>
The end-users MAY be willing to accept a changeover to IPv6, but will<br>
NOT accept that some of their applications will no longer work as<br>
before. From this observation it becomes obvious that it is<br>
absolutely essential that provisions are standard installed and<br>
enabled on any general purpose machine (the vast majority of systems<br>
connected to the Internet) that is provided for IPv6 communication<br>
and potentially has to run IPv4-only applications to continue<br>
communicating as before when communicating using IPv6. While the<br>
demand for mandatory provisions on every general purpose machine<br>
capable of communicating using IPv6 may seem a tall order,<br>
it should be realized that this approach is much more realistic<br>
then expecting&nbsp;ALL applications to be made IPv6 compatible:<br>
compared to thousands of applications that would need conversion<br>
requiring all application developers to follow suit, the number of<br>
communication stack implementations on general purpose machines is<br>
very small and is made by only a handful of developers.<p></p></span></p>

</div>

</div>

</div>

</div>

Gmane