I-D Action:draft-ietf-v6ops-v4v6tran-framework-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : Framework for IP Version Transition Scenarios
	Author(s)       : B. Carpenter, et al.
	Filename        : draft-ietf-v6ops-v4v6tran-framework-00.txt
	Pages           : 7
	Date            : 2010-11-30

This document sets out a framework for the presentation of scenarios
and recommendations for a variety of approaches to the transition
from IPv4 to IPv6, given the necessity for a long period of co-
existence of the two protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v4v6tran-framework-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.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Re: I-D Action:draft-ietf-v6ops-v4v6tran-framework-00.txt

i am cheered by

   2.  The documents are addressed to service providers who have taken
       the decision to support IPv6, have acquired basic knowledge and
       skills, have determined how they will obtain upstream IPv6
       connectivity, and are ready to write their operational plan for
       transition.

i am uncheered by the following section's weak specificity to ipv6
deployent.

randy
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Re: I-D Action:draft-ietf-v6ops-v4v6tran-framework-00.txt

On Dec 1, 2010, at 1:57 PM, Randy Bush wrote:

> i am cheered by
> 
>   2.  The documents are addressed to service providers who have taken
>       the decision to support IPv6, have acquired basic knowledge and
>       skills, have determined how they will obtain upstream IPv6
>       connectivity, and are ready to write their operational plan for
>       transition.
> 
> i am uncheered by the following section's weak specificity to ipv6
> deployment.

Thanks. Do you have specific suggestions for Brian?
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Re: I-D Action:draft-ietf-v6ops-v4v6tran-framework-00.txt

On 2010-12-02 08:57, Randy Bush wrote:
> i am cheered by
> 
>    2.  The documents are addressed to service providers who have taken
>        the decision to support IPv6, have acquired basic knowledge and
>        skills, have determined how they will obtain upstream IPv6
>        connectivity, and are ready to write their operational plan for
>        transition.
> 
> i am uncheered by the following section's weak specificity to ipv6
> deployent.

Yes, it's generic. Please send text, although it may be that the specificity
will only appear in the target documents.

   Brian
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Re: NAT64+DNS64

On Nov 22, 2010, at 11:20 PM, Mikael Abrahamsson wrote:

> Also, since a lot of programs is going to be converted to dual stack now (I'm afraid a lot of software is still
being written with v4 only APIs), wouldn't it make sense to publish example code (for different OSes) that
does the right thing as an informational document?

The Happy Eyeballs Draft actually does have one approach, which I would suggest you read. AFAIK, it is
OS-specific, which says to me that for other OS's there may be different and perhaps superior approaches.

T'wer it me, and I had the commit bit on an open source stack (which I don't), I would write an API call that
could be called with a name and would return either an error code or an open+connected socket, call it
something obvious like "connectbyname", and encourage applications to call it. I'm not the first to have
made this observation.
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Re: I-D Action:draft-ietf-v6ops-v4v6tran-framework-00.txt

>> i am uncheered by the following section's weak specificity to ipv6
>> deployent.
> 
> Yes, it's generic. Please send text, although it may be that the specificity
> will only appear in the target documents.

documents should describe scenarios for real transition to ipv6, not life
extensions to ipv4 or other things best handled in other wgs.

randy
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Re: NAT64+DNS64

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Re: NAT64+DNS64

On 1 December 2010 12:26, Fred Baker <fred@...> wrote:
>
> On Nov 22, 2010, at 11:31 PM, Roman.Arcea@... wrote:
>
> As per Cameron words, he did not observe this behavior, so we can conclude
> it is just related to some implementations.
>
> It is OS-specific, network dependent, and due to the structure of the
> sockets API, application specific.

In Advanced Programming in the UNIX Environment, Richard Stevens
described two separate "open server" implementations:

    (1) forked, where the child passes an opened file descriptor (or
error) back to the parent over a pipe created just before the fork,
and

    (2) daemonized, where clients connect to a well-known named pipe
in the filesystem, and receive back an opened file descriptor (or
error) over that named pipe.

Any platform that supports FD passing in this classic sockets API
sense (or emulates it), can easily support this sort of thing.

Whether these implementation ideas are awesome or not, a good idea or
not, or even adequate or not, is an exercise left to the implementor.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Re: NAT64+DNS64

Hi, Fred,

> T'wer it me, and I had the commit bit on an open source stack (which
> I don't), I would write an API call that could be called with a name
> and would return either an error code or an open+connected socket,
> call it something obvious like "connectbyname", and encourage
> applications to call it. I'm not the first to have made this
> observation.

See: http://tools.ietf.org/html/draft-gont-tcpm-tcp-soft-errors-01#section-6

At the last IETF someone (rightfully) said that the API should have a
function named "give me a f* connection"  which should probably take
an URL, and return a connected socket, as you indicate.

My take with all these issues is that many of these problems have to do
with apps using APIs that are of lower level than they should be.

Thanks,
--

-- 
Fernando Gont
e-mail: fernando@... || fgont@...
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Re: NAT64+DNS64

On 2010-12-02 09:23, Fred Baker wrote:
> On Nov 22, 2010, at 11:20 PM, Mikael Abrahamsson wrote:
> 
>> Also, since a lot of programs is going to be converted to dual stack now (I'm afraid a lot of software is
still being written with v4 only APIs), wouldn't it make sense to publish example code (for different
OSes) that does the right thing as an informational document?
> 
> The Happy Eyeballs Draft actually does have one approach, which I would suggest you read. AFAIK, it is
OS-specific, which says to me that for other OS's there may be different and perhaps superior approaches.
> 
> T'wer it me, and I had the commit bit on an open source stack (which I don't), I would write an API call that
could be called with a name and would return either an error code or an open+connected socket, call it
something obvious like "connectbyname", and encourage applications to call it. I'm not the first to have
made this observation.

Nor am I the first to point out that Java has done this for years now.

   Brian
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops