[v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt]

Hi,

This version is updated in response to WG Last Call. There are a lot of changes.
You can see the diffs at
http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-icp-guidance-03.txt

The most important change is that the text on PA prefixes, especially on multiple
PA prefixes, has been changed in response to comments that it was unrealistic.

Other changes were relatively minor, but there are several new points from
Erik Nygren's extensive review (thanks, Erik!). Here are some detailed responses
to Erik's suggestions:

Most of Erik's changes have been implemented, but quite often reworded
for stylistic reasons. Some changes have been moved elsehwere in the document.
Some cosmetic changes have not been included due to stylistic preference.

Various changes related to multiple PA prefixes have not been applied,
because that text has been changed anyway and needs complete review.

> + Additionally, many deployments of IPv6-only clients (such as those 
> + using NAT64 for their IPv4 connectivity) will have the clients 
> + communicating with their DNS resolvers over IPv6, and those DNS resolvers
> + may in-turn be dual-stacked or IPv4-only.

We don't see that - a DNS64 by definition needs to communicate with the IPv4 world.
Anyway, this point seems distracting for an ICP. They just need to dual stack
their own DNS; that is sufficient advice.

> +<t>Because dual-stacked clients may switch between IPv4 and IPv6, as well as switching 
> +between multiple IPv6 addresses when privacy addressing is in-use, special care will
> +need to be taken with any load balancers using IP addresses for session affinity as
> +the same client might otherwise go to different servers for subsequent requests.</t>

Point moved to the new "complexity" section, and that section has been moved later
in the document to improve logical flow.

> +<t>A surrogate (such as an HTTP reverse proxy) <xref target="RFC3040"/>...

We prefer to refer to RFC2616 where proxy behaviour is actually specified.
RFC3040 is only a taxonomy document from a not-very-successful WG. (BC: I've also never
understood the phrase "reverse proxy"; it's just a proxy that happens to be near the
server instead of near the client, but what it actually does is the same. Also,
"proxy" and "surrogate" mean the same thing in English.)

> +<t>For multi-tier applications, it may be initially sufficient to dual-stack
> +the Web Tier (often operating as an HTTP surrogate) and to provide IPv6 
> +connectivity to back-end application layers in a later phase.</t>

This point is already made in the Introduction.

> + <section anchor="client" title="Client Software">
>    <t>One important recommendation here is that all applications should use domain names, which are IP-version-independent,

That isn't restricted to clients - it should apply everywhere. In any case we can't really
tell ICPs to change their clients' software.

>   Note that 
> +  the behavior of dual-stack clients will vary between operating systems and browsers.  For example, some client
> +  implementation of "happy eyeballs" <xref target="RFC6555"/> may result in a dual-stack client making 
> +  connections to the same domain name over both IPv4 and IPv6 over time.</t>

Moved to the new "complexity" section.

>  <section anchor="cdn" title="Content Delivery Networks">

We didn't understand the reason for the changes suggested here, and we don't think the CDN
topic should be embedded in the "complexity" section. It's basic for most ICPs, these days.

> -<t>As far as possible, however, mutual dependency between IPv4 and IPv6 operations should be avoided.
> +<t>As far as possible, however, mutual dependency between IPv4 and IPv6 availability should be avoided.

Disagree, the point is more general than just availability.

    Brian + Sheng

-------- Original Message --------
Subject: [v6ops] I-D Action: draft-ietf-v6ops-icp-guidance-03.txt
Date: Thu, 30 Aug 2012 23:59:25 -0700
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
CC: v6ops@ietf.org

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           : IPv6 Guidance for Internet Content and Application Service Providers
	Author(s)       : Brian Carpenter
                          Sheng Jiang
	Filename        : draft-ietf-v6ops-icp-guidance-03.txt
	Pages           : 24
	Date            : 2012-08-30

Abstract:
   This document provides guidance and suggestions for Internet Content
   Providers and Application Service Providers who wish to offer their
   service to both IPv6 and IPv4 customers.  Many of the points will
   also apply to hosting providers, or to any enterprise network
   preparing for IPv6 users.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-icp-guidance-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-icp-guidance-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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