Subject: Re: [BEHAVE] draft-hamarsheh-behave-biav2-03 VS draft-ietf-behave-v4v6-bih

From: <[email-masked]>
Date: Thu, 4 Nov 2010 13:18:45 +0100

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 accesses:). 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:[email-masked]]
Sent: 04. marraskuuta 2010 13:47
To: Savolainen Teemu (Nokia-MS/Tampere)
Cc: ,; [email-masked]
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.

---

From: <[email-masked]>
Date: Thu, 4 Nov 2010 15:17:40 +0100

Hi,

The A record synthesis was already part of the original RFC2767 section 2.2. Catching of the reverse DNS queries was missing, and based on discussion that took place in IETF#77 it was added to BIH-00 draft published at June for IETF#78. The BIH-00 on the hand was direct result of merging of the 2767bis- and 3338bis-drafts, of which -00s were published at October 2009 (for IETF#76), based on discussions that took place e.g. at IETF#75 and on the work CMCC had done before that. I don't know much about history of the original BIA and BIS RFCs - I wasn't following IETF when they were created. However, I'm confident there are several people on this list who know the origins of the work far better.

For the other details, I will read your draft later more thoroughly, but it would also help if you would contribute details directly to the working group draft. The draft then notes the contributors.

The problem for integrating the generic solution is not cost, but will. The Behave WG is only chartered to:
--
Apr 2011 Submit to IESG: host-based NAT46 translation for IPv4-only applications to access IPv6-only servers (std)
--
And as you can see from the discussion, we are even having some trouble agreeing whether the "IPv6-only" means strictly IPv6-only servers or servers that a host can reach only via IPv6..

Feature for "host-based NAT64 translation for IPv6-only applications to access IPv4-only servers" is not in the chartered to-do list... and probably could be solved "BIS-style" just by running NAT64 and DNS64 functions inside a host rather than at the network?-) One could e.g. port Ecdysis, http://ecdysis.viagenie.ca/, to Nokia N900..  "BIA-style" IPv6->IPv4 host based translation would require rechartering, I believe.

Best regards,

Teemu

From: ext Goossens, Marnix [mailto:[email-masked]]
Sent: 04. marraskuuta 2010 14:48
To: Savolainen Teemu (Nokia-MS/Tampere)
Cc: [email-masked]; [email-masked]
Subject: RE: [BEHAVE] draft-hamarsheh-behave-biav2-03 VS draft-ietf-behave-v4v6-bih

Hi again Teemu

A quick reply, if needed I can give more extensive detail later on:

We have finished the work on our version of BIA (we called it BIAv2) some 6months ago. Since than some other drafts have appeared from other authors, including another BIAv2 that was developed independent of ours and is very similar but misses a few tricky points we have tackled, and this BIH. It is probably not clear from the motivation or introduction, but we tackle many small practical issues not handled by BIA or BIH, like DNS involvement etc. As an example, a IPv4-only client application could not address and IPv6(connectivity)-only server application, as it would only have an AAAA record and no A record, and that could not be solved by either BIA nor BIH... We solved several of this kind of imperfections, trivial details maybe, but that would prevent BIA and BIH to be really used on a wide-spread scale...

We don't mind too much about wether our proposal is a seperate specification, or would be used to adapt BIH... As an academic research group we absolutely need to be able to get official credit somehow however, as our funding depends on publications and contributions to standards (that requirement is not our first priority, but we don't have a choice).

I tend to agree about the issue of IPv6-only applications over IPv4 communication, it is not a big issue... But as our solution was generic as it was, we could integrate that solution at no extra cost, so why leave it out, when it was more or less implicitely included without any penalty in our proposal?

You are quite right about the tird option for BIH, it is missing. We had to write that email on short notice, and we missed it somehow...

Kind regards

Marnix

________________________________
Van: [email-masked] [[email-masked]]
Verzonden: donderdag 4 november 2010 13:18
Aan: Goossens, Marnix
CC: [email-masked]; [email-masked]
Onderwerp: RE: [BEHAVE] draft-hamarsheh-behave-biav2-03 VS draft-ietf-behave-v4v6-bih
Hi,

            Host                                      Server

Best regards,

Teemu

Hello Teemu

Kind regards,

Marnix Goossens

---

From: "Goossens, Marnix" <[email-masked]>
Date: Thu, 4 Nov 2010 11:46:42 +0000

Hello Teemu

Kind regards,

Marnix Goossens

---

From: "Goossens, Marnix" <[email-masked]>
Date: Thu, 4 Nov 2010 12:47:53 +0000

Hi again Teemu

Kind regards

Marnix

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

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 accesses:). 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.

            Host                                      Server

Best regards,

Teemu

Hello Teemu

Kind regards,

Marnix Goossens

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Nov 2010 14:42:18 +1300

Hi,

My feeling after a superficial reading of the draft is that
as long as it doesn't deviate in any way from the energing BEHAVE
specifications, it doesn't need to be standards track material.
It's really just a use case.

Since it is overkill in terms of the agreed BEHAVE scenarios,
it would have a hard time being adopted here anyway. So shouldn't
we suggest that the authors consider an alternative publication
stream, in particular an independent submission to the RFC Editor?

A document like this, supported by running code, seems ideal
for that stream.

I do have a few specific comments:

1. The draft doesn't consider some of the tricky aspects:
referrals, multihoming, multi-interface.

2. The internal address mapping section asks for whole /8 from IANA for
locally assigned IPv4 addresses. I don't see any chance of that happening,
and why would it need 2**24 IPv4 addresses anyway?
Why not use RFC1918 space? (Use whichever RFC1918 prefix you want,
as long as it is not also used on the physical interface.)

3. The security considerations are really not sufficient.

Regards
   Brian Carpenter

On 2010-11-05 00:46, Goossens, Marnix wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave