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

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Aug 2012 08:14:55 +0100

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: [email-masked]
To: [email-masked]
CC: [email-masked]

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
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Tore Anderson <[email-masked]>
Date: Fri, 31 Aug 2012 10:58:19 +0200

Regarding PI addresses, the new version says:

«This option is available to an ICP willing to deal directly with the
relevant Regional Internet Registry and pay the associated fees»

This is misleading, at least in the RIPE NCC service area. An ICP could
opt to obtain PI addresses through his LIR of choice. This LIR is then
called a «sponsoring LIR». The RIPE NCC very obviously tries to steer PI
users in that direction - a single PI resource registered through a
sponsoring LIR costs €50/year (which will on the LIR's invoice), while a
direct assignment from the NCC costs €1300/year + a one-time fee of
€2000. See
<http://www.ripe.net/lir-services/member-support/info/billing/ripe-ncc-billing-information>.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Aug 2012 11:41:33 +0100

On 31/08/2012 09:58, Tore Anderson wrote:
> This is misleading, at least in the RIPE NCC service area. 

Ah, OK, would it be accurate to simply delete the word "Regional"?

   Brian

> An ICP could

---

From: Tore Anderson <[email-masked]>
Date: Fri, 31 Aug 2012 13:12:42 +0200

* Brian E Carpenter

> Ah, OK, would it be accurate to simply delete the word "Regional"?

Strictly speaking, I suppose so. But the message is still a bit
confusing. The «willing to deal directly with» formulation is in all
likelihood a red herring, because the ICP will be already dealing
directly with an LIR - his ISP. And which ICP would care about €50/year?

The document continues in the same vein: «only large content providers
can justify the bother and expense of obtaining a PI prefix». Can't say
I agree. The bother and expense is for all practical purposes
negligible, especially when compared to the potential bother and expense
associated with renumbering out of a PA assignment down the road.

It is probably a bigger hurdle for the ICP (compared to getting a PA
assignment from an ISP) to acquire and set up BGP-speaking routers.
However, it is also possible to have the upstream ISP(s) advertise the
PI prefix on the ICP's behalf, so even that might not be a problem after
all.

Truth to be told I don't see any real reason why an ICP shouldn't go for
PI from day one. Except for altruism, that is.

(I'm not well informed when it comes to the other four RIRs' PI
policies, so the above might be limited only to the RIPE service area.)

Best regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Aug 2012 13:21:12 +0100

> Except for altruism, that is.

Exactly. I don't believe the IETF should be making it seem that
blowing up BGP4 is the recommended approach. We should actually be
advocating altruism IMHO.

Regards
   Brian

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 31 Aug 2012 13:54:19 +0100

On 31/08/2012 12:12, Tore Anderson wrote:
> I agree.

+1.

PI is easy to get and there are plenty of smaller organisations who depend
on it for their business requirements (at least for ipv4).  There are no
substantial issues with routing PIv6 address space, because the minimum
assignment size is /48, which corresponds with the RIRs' recommendations on
minimum prefix filter length.

Nick

---

From: Joel jaeggli <[email-masked]>
Date: Fri, 31 Aug 2012 07:29:15 -0700

> advocating altruism IMHO.

The IETF should make recommendations that responsible network operators
can follow without interfering with their business.

With respect to PA address space, it should be understood that some of
the internet content providers this document addresses will be deploying
from the networks of their colo providers, ASPs, cloud providers and so
on. these will be necessarily numbered out of provider assigned address
space for convenience, because the provider itself is multihomed and so
forth.

joel

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Aug 2012 15:53:32 +0100

Nick,

On 31/08/2012 13:54, Nick Hilliard wrote:
> on it for their business requirements (at least for ipv4).  

It's a solution, not a requirement. It may well be the *only* solution in
IPv4, but this is about IPv6 which needs to be much more scaleable than
IPv4 to make any sense.

> There are no

That is, however, just a pragmatic choice and with the *current* size of the
IPv6 RIB, simply not an issue. The point is that we (the IETF) need to set
things rolling in a way that will scale to an IPv6 RIB many times bigger
than the current IPv4 RIB. Recommending PI unconditionally is, in my
opinion, highly irresponsible in that context.

As document editors we will of course do what the WG chairs determine
is the WG consensus. As an individual contributor, I will continue to press
for recognition of the PA approach.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Aug 2012 16:29:15 +0100

> can follow without interfering with their business.

Yes. But we are also supposed to worry about the long-term health
of the network; the difficulty is finding the right balance.

> space for convenience, because the provider itself is multihomed and so

Absolutely, and the draft should recognise that as well as the PI option.

Specific suggestions for rewriting the text would be welcome. That's the
first two paragraphs at
http://tools.ietf.org/html/draft-ietf-v6ops-icp-guidance-03#section-5.1

   Brian