Document Action: 'Application Aspects of IPv6 Transition' to Informational RFC

The IESG has approved the following document:

- 'Application Aspects of IPv6 Transition '
   <draft-ietf-v6ops-application-transition-03.txt> as an Informational RFC

This document is the product of the IPv6 Operations Working Group. 

The IESG contact persons are David Kessens and Bert Wijnen.

Technical Summary

 As IPv6 networks are deployed and the network transition discussed,
 one should also consider how to enable IPv6 support in applications
 running on IPv6 hosts, and the best strategy to develop IP protocol
 support in applications.  This document specifies scenarios and
 aspects of application transition. It also proposes guidelines on
 how to develop IP version-independent applications during the
 transition period.

Working Group Summary

 This document is a product of the v6ops working group.

Protocol Quality

 David Kessens reviewed this document for the IESG.
 This document was subject to a two week IETF last call
 and no comments were received.

RFC Editor note:

In Section 1, add as the second-to-last paragraph:

In the context of this document, the term "application" covers all
kinds of applications, but the focus is on those network applications
which have been developed using relatively low-level APIs (such as the
"C" language, using standard libraries). Many such applications could
be command-line driven, but that is not a requirement.

In section 2, rewrite:

OLD:

Note that this draft does not address DCCP and SCTP considerations at
this phase.

NEW:

The first two cases are not interesting in the longer term; only few
applications are inherently IPv4- or IPv6-specific, and should work
with both protocols without having to care about which one is being
used.

Note that this memo does not address DCCP and SCTP considerations.

In section 3.2:

OLD:

Hence an operational technique is to use "service names" in the DNS,
that is, if a node is offering multiple services, but only some of
them over IPv6, add a DNS name for each of these services (with the
associated A/AAAA records), not just a single name for the whole node,
also including the AAAA records.

NEW:

Hence an operational technique is to use "service names" in the DNS,
that is, if a node is offering multiple services, but only some of
them over IPv6, add a DNS name for each of these services or group of
services (with the associated A/AAAA records), not just a single name
for the physical machine, also including the AAAA records.

Add as the 3rd paragraph in section 4:

Note that the first two cases, IPv4-only and IPv6-only applications,
are not interesting in the longer term; only few applications are
inherently IPv4- or IPv6-specific, and should work with both protocols
without having to care about which one is being used.

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce