Subject: [v6ops] draft-ietf-v6ops-icp-guidance WGLC

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 6 Aug 2012 05:29:57 +0000

This is to open a two week Working Group last Call on 

http://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance
  "IPv6 Guidance for Internet Content and Application Service Providers",
  Brian Carpenter, Sheng Jiang, 10-Jul-12

Please read it now. We are interested in, among other things, technical commentary on the draft and the working group's perception on its usefulness to its target audience.

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 06 Aug 2012 18:51:14 -0400

Brian/Sheng,

Overall, this came out quite good.  Did a full read over, and only had one
comment/suggestions.

In section 5.3 [DNS] , you made good note of some devices such as XP which
may only use IPv4 connectivity for DNS with query capability for A and
AAAA.

Would it be advisable to also add the reverse case were an IPv6-only
addressed (or DNSv6 address supplied) host can make queries for A records?
(perhaps this detail is not important and the existing point gets the
thought across).

Other then that trivial item, looks good.

Support 

Regards,

Victor K

On 12-08-06 1:29 AM, "Fred Baker (fred)" <[email-masked]> wrote:

>perception

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 6 Aug 2012 20:59:02 -0700

> Please read it now. We are interested in, among other things, technical commentary on the draft and the working group's perception on its usefulness to its target audience.

Useful.

Support.

Few technical comments here, few editorial comments sent direct to authors

Does this exist in the "real world"  ?

"An ICP that has multiple connections via multiple ISPs will have
   multiple PA prefixes.  This results in multiple PA-based addresses
   for the servers, or for load balancers if they are in use."

It seems like NPTv6 is a much more modern approach that is much more
likely to be deployed ... or some method involving the load balancers
doing a proxy / load balancing function for the new and legacy prefix.

It would also be good to reference RA Guard (rfc 6105), ND Cache
issues (RFC6583),  p2p /127 (RFC 6164)

It might also be prudent to mention that proxies are commonly
implemented in load balancers.  Nearly all load balancers i know of
have an Ipv6 to ipv4 proxy function (including Amazon ELB)

12.  Operations and Management -- might be worth noting that many
large entities have not fully made IPv6 work just like IPv4 in OAM...
and in many cases, some hashing or aliasing is used to represnt the
128 bit IPv6 address into the legacy IPv4 data base field.  This is
not what people should do, but this is what many "IPv6 leaders" have
done to make IPv6 work without boiling the ocean in terms of project
costs and timelines.

---

From: Tore Anderson <[email-masked]>
Date: Tue, 07 Aug 2012 09:32:29 +0200

* Fred Baker (fred)

> http://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance "IPv6
> Guidance for Internet Content and Application Service Providers",
> Please read it now. We are interested in, among other things,
> technical commentary on the draft and the working group's perception
> on its usefulness to its target audience.

Support.

One comment, regarding section 5.2: «It is worth noting that whereas
OSPF and RIP differ significantly between IPv4 and IPv6, IS-IS has the
advantage of handling them both in a single instance of the protocol».

I am under the impression that OSPFv3 also has this advantage (cf. RFC
5838: «Support of Address Families in OSPFv3»). I haven't yet played
with this functionality myself, though.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Aug 2012 10:17:15 +0100

> (perhaps this detail is not important and the existing point gets the

Isn't that case going to be tied intimately to techniques such as DNS64,
because the A record is of no immediate use to an IPv6-only node?

A dual stack node provisioned only with a v6-accessible DNS server is
certainly a theoretical possibility, but is it likely?

I agree we could mention the point.

Thanks

     Brian
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
> .
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Aug 2012 10:24:16 +0100

>    for the servers, or for load balancers if they are in use."

I know that there are instances of this, and it is certainly supposed to work.
Numerically, it's probably not important today, because early-adopter ICPs
are big enough to request a PI prefix.

> likely to be deployed ... 

For content providers???

> or some method involving the load balancers

That could be, but do we have any current practice to describe?

> issues (RFC6583),  p2p /127 (RFC 6164)

Yes

> have an Ipv6 to ipv4 proxy function (including Amazon ELB)

Yes, if you are doing that sort of LB. There are other approaches,
but that's a whole other topic.

> done to make IPv6 work without boiling the ocean in terms of project

Oh yuck! If we mention this, surely it should be in a negative way?

Thanks

   Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 7 Aug 2012 02:24:58 -0700 (PDT)

Hi,

>________________________________
> From: Fred Baker (fred) <[email-masked]>
>To: "[email-masked]" <[email-masked]> 
>Cc: V6ops Chairs <[email-masked]>; Ron Bonica <[email-masked]> 
>Sent: Monday, 6 August 2012 3:29 PM
>Subject: [v6ops] draft-ietf-v6ops-icp-guidance WGLC
> 
>_

Having reviewed it recently and reviewed the results of the changes I suggested, I think it is fine as it is and should be published.

As for usefulness to it's target audience, I think it will be very useful, as perhaps it may have prevented the following ICP choosing to deploy an IPv6 only production network and then completely misusing NAT64 to try to provide IPv4 and IPv6 client facing services.

"IPv6 is hard."

http://lists.ausnog.net/pipermail/ausnog/2012-July/014038.html

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Aug 2012 10:31:53 +0100

Tore,

> with this functionality myself, though.

Good question. I have no idea, so I have sent a query to the cluenet list.

Thanks
   Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 7 Aug 2012 02:39:57 -0700 (PDT)

Hi,

----- Original Message -----
> From: Brian E Carpenter <[email-masked]>
> To: Cameron Byrne <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>; V6ops Chairs <[email-masked]>; Ron Bonica <[email-masked]>
> Sent: Tuesday, 7 August 2012 7:24 PM
> Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC
> 
<>
>>  likely to be deployed ... 

Wouldn't NPTv6's Experimental status mean it shouldn't really be suggested in an advisory document like this? If it was mentioned, then I think there'd have to be text discussing it's drawbacks in ICP scenarios e.g. the consequences of content hosts/applications not knowing their own IPv6 identity, and discussion around NPTv6 in a situation where the "cloud" application traffic is encrypted (I think this is going to increase significantly with the rapid adoption of BYO devices and Wifi offload).

Regards,
Mark.

---

From: Gert Doering <[email-masked]>
Date: Tue, 7 Aug 2012 14:11:16 +0200

Hi,

On Tue, Aug 07, 2012 at 02:24:58AM -0700, Mark ZZZ Smith wrote:
> As for usefulness to it's target audience, I think it will be
> very useful, as perhaps it may have prevented the following ICP
> choosing to deploy an IPv6 only production network and then completely
> misusing NAT64 to try to provide IPv4 and IPv6 client facing services.

So how exactly would that be "misuse"?

It's quite reasonable to run single-stack inside, and if you need lots
of addresses, make that IPv6-only.  The outside needs to be dual-stacked,
and NAT64 (with preconfigured mappings) will do that for you, in a 
nice and stateless way.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 7 Aug 2012 06:12:08 -0700

On Aug 7, 2012 2:39 AM, "Mark ZZZ Smith" <[email-masked]> wrote:
> > Cc: "[email-masked]" <[email-masked]>; V6ops Chairs <
[email-masked]>; Ron Bonica <[email-masked]>
> Wouldn't NPTv6's Experimental status mean it shouldn't really be
suggested in an advisory document like this? If it was mentioned, then I
think there'd have to be text discussing it's drawbacks in ICP scenarios
e.g. the consequences of content hosts/applications not knowing their own
IPv6 identity, and discussion around NPTv6 in a situation where the "cloud"
application traffic is encrypted (I think this is going to increase
significantly with the rapid adoption of BYO devices and Wifi offload).
> Mark.

NPTv6 is not really the focus of my comment. The focus was supposed to be
using 2 prefixes for multihoming or migrating isps.

I dont think anyone would do this today. Doing it, afaik, would be a
science experiment and therefore should not be a recommended approach. I
understand ipv6 was designed to work this way. .... But afaik, it is not
really exercised.  If someone has done it in a production network, that
would be good to know

CB

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Aug 2012 14:42:59 +0100

Change of subject header, to separate out this topic:

On 07/08/2012 14:12, Cameron Byrne wrote:
> science experiment 

I think that's unfair and kind of ignores draft-v6ops-multihoming-without-ipv6nat

It works today. There are known difficulties with address selection
and with ingress filtering, of course. And it's a bit more fiddly to
configure routing and DNS for IT crews used to the old way of doing things.
But it really isn't unknown territory.

> and therefore should not be a recommended approach. I

If we are only addressing a few thousand sites, sure, but how else do
you suggest we deal with content providers by the million?

> really exercised.  If someone has done it in a production network, that

Yes, facts are always good.

    Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 7 Aug 2012 15:27:44 +0000

In the context of RFC 5838, OSPFv3 can now handle both protocols. So the operator has a choice.

> with this functionality myself, though.

----------------------------------------------------
The ignorance of how to use new knowledge stockpiles exponentially. 
   - Marshall McLuhan

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 7 Aug 2012 13:31:47 -0700 (PDT)

Hi Gert,

----- Original Message -----
> From: Gert Doering <[email-masked]>
> To: Mark ZZZ Smith <[email-masked]>
> Cc: Fred Baker (fred) <[email-masked]>; "[email-masked]" <[email-masked]>; V6ops Chairs <[email-masked]>; Ron Bonica <[email-masked]>
> Sent: Tuesday, 7 August 2012 10:11 PM

> and NAT64 (with preconfigured mappings) will do that for you, in a 

I think when you use something outside of the scenario it was designed for, there is a risk that things won't work well.

According to RFC6145, 

   This document describes stateful NAT64 translation, which allows
   IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or
   ICMP.  One or more public IPv4 addresses assigned to a NAT64
   translator are shared among several IPv6-only clients.  When stateful
   NAT64 is used in conjunction with DNS64, no changes are usually
   required in the IPv6 client or the IPv4 server.

So NAT64 wasn't designed for a scenario where IPv4-only clients contact IPv6 servers. That's not to say it won't work, but it may not work well, and with their very general conclusion that "IPv6 is hard" (and plenty of people's experience is that it isn't anywhere near as hard as their story suggests), it didn't work well for them. That says to me that they weren't using the right tool for the job. They were misusing the tool by choosing the wrong one.

I think they developed or were given false expectations of what NAT64 would do for them, and that is where they were let down. Unfortunately some brief Internet searching on deployment choices or advice, or even an email to the mailing list they posted their story to, asking people's advice, would probably have saved them a lot of grief. This draft should hopefully prevent those sorts of false expectations, and false conclusions about how hard or not IPv6 is deploy in the future.

Regards,
Mark.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 7 Aug 2012 21:07:56 +0000

On Aug 7, 2012, at 1:31 PM, Mark ZZZ Smith wrote:

> So NAT64 wasn't designed for a scenario where IPv4-only clients contact IPv6 servers. 

Your quote is from RFC 6146, and you are correct with regard to stateful NAT64. 

RFC 6145, which is stateless and uses an IPv6 address that contains an embedded IPv4 address, is very much defined to enable bidirectional session initiation between systems with the stated type of address.

https://tools.ietf.org/html/rfc6052
6052 IPv6 Addressing of IPv4/IPv6 Translators. C. Bao, C. Huitema, M.
     Bagnulo, M. Boucadair, X. Li. October 2010. (Format: TXT=41849 bytes)
     (Updates RFC4291) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6144
6144 Framework for IPv4/IPv6 Translation. F. Baker, X. Li, C. Bao, K.
     Yin. April 2011. (Format: TXT=67181 bytes) (Status: INFORMATIONAL)

https://tools.ietf.org/html/rfc6145
6145 IP/ICMP Translation Algorithm. X. Li, C. Bao, F. Baker. April
     2011. (Format: TXT=76484 bytes) (Obsoletes RFC2765) (Status: PROPOSED
     STANDARD)

https://tools.ietf.org/html/rfc6146
6146 Stateful NAT64: Network Address and Protocol Translation from
     IPv6 Clients to IPv4 Servers. M. Bagnulo, P. Matthews, I. van
     Beijnum. April 2011. (Format: TXT=107954 bytes) (Status: PROPOSED
     STANDARD)

https://tools.ietf.org/html/rfc6147
6147 DNS64: DNS Extensions for Network Address Translation from IPv6
     Clients to IPv4 Servers. M. Bagnulo, A. Sullivan, P. Matthews, I. van
     Beijnum. April 2011. (Format: TXT=75103 bytes) (Status: PROPOSED
     STANDARD)

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 8 Aug 2012 01:35:35 +0000

I think both multiple prefix and NPTv6 for multihoming should be mentioned and stated that each of them has their own issues.

As discussed in INTAREA meeting in Vancouver, NPTv6 has referral issues, which are difficult to solve. Multiple prefix model was in original IPv6 design, but has not yet been widely proved yet. We at least know there are filtering and address selection issues.

Giving the fact, there is no best current practice yet, we should document potential solutions and their issues WITHOUT a recommendation, if we are going to discuss the best way for multihoming.

However, as far as I concern, this document does not discuss multihoming solutions at all. It only mentions these solutions as potential scenarios when discusses routing impacts.

Best regards,

Sheng

From: [email-masked] [mailto:[email-masked]] On Behalf Of Cameron Byrne
Sent: Tuesday, August 07, 2012 9:12 PM
To: Mark ZZZ Smith
Cc: [email-masked]; V6ops Chairs; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC

On Aug 7, 2012 2:39 AM, "Mark ZZZ Smith" <[email-masked]<mailto:[email-masked]>> wrote:
> > From: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>
> > To: Cameron Byrne <[email-masked]<mailto:[email-masked]>>
> > Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; V6ops Chairs <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>
> >>  On Sun, Aug 5, 2012 at 10:29 PM, Fred Baker (fred) <[email-masked]<mailto:[email-masked]>>
> > wrote:

NPTv6 is not really the focus of my comment. The focus was supposed to be using 2 prefixes for multihoming or migrating isps.

I dont think anyone would do this today. Doing it, afaik, would be a science experiment and therefore should not be a recommended approach. I understand ipv6 was designed to work this way. .... But afaik, it is not really exercised.  If someone has done it in a production network, that would be good to know

CB

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 7 Aug 2012 21:06:20 -0700

> Yes, facts are always good.

One of the keys here that i overlooked is the ICP will certainly not
be using SLAAC.  They will be using static addresses manual, automated
manually (Puppet, ...) , or via DHCPv6.  That said, this is an issue
of automation and instrumentation on how addresses are assigned and
therefore should not be much of challenge, including running multiple
prefixs in a short transition period.

Meaning, this problem is solved in IPv4 for ICPs and those same IPv4
solution apply in IPv6.

CB

---

From: joel jaeggli <[email-masked]>
Date: Tue, 07 Aug 2012 22:29:12 -0700

On 8/7/12 9:06 PM, Cameron Byrne wrote:
>> I think that's unfair and kind of ignores 
>> draft-v6ops-multihoming-without-ipv6nat It works today. There are 
>> known difficulties with address selection and with ingress filtering, 
>> of course. And it's a bit more fiddly to configure routing and DNS 
>> for IT crews used to the old way of doing things. But it really isn't 
>> unknown territory.

I think characterizing the criticism as unfair is unfair. As far as I'm 
aware nobody actually serves from two PA prefixes from the same hosts in 
practice... While DNS GLB is suitable for doing that, what it isn't 
suitable for is optimizing provider exit selection, which BGP is rather 
good for and which proper BCP 38 RPF checks prevent unless I advertise 
the respective prefixes to my upstream...

So either my hosting provider needs to be multihomed using pi or 
delegates PA that others are willing to carry, or I need to be... and 
what I use the GLB for is to direct traffic to one instance of a service 
or another.

finding a multi-homed hosting provider in ipv4 land isn't that hard it 
shouldn't be in IPv6 either.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 8 Aug 2012 14:33:55 +0900

On Tue, Aug 7, 2012 at 10:42 PM, Brian E Carpenter <
[email-masked]> wrote:

> draft-v6ops-multihoming-without-ipv6nat
>

If I were a content provider, I would think twice before choosing an
architecture that breaks TCP connections when upstreams go down.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 8 Aug 2012 02:14:04 -0700 (PDT)

Hi Fred,

----- Original Message -----
> Cc: Gert Doering <[email-masked]>; "[email-masked]" <[email-masked]>; V6ops Chairs <[email-masked]>; Ron Bonica <[email-masked]>
> Sent: Wednesday, 8 August 2012 7:07 AM
> RFC 6145, which is stateless and uses an IPv6 address that contains an embedded 
> IPv4 address, is very much defined to enable bidirectional session initiation 
> between systems with the stated type of address.
> 
<snip>

Thanks for the references. To clarify, this ICP used Stateful NAT64.

Regards,
Mark.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 8 Aug 2012 02:34:22 -0700 (PDT)

> From: Lorenzo Colitti <[email-masked]>
>To: Brian E Carpenter <[email-masked]> 
>Cc: V6ops Chairs <[email-masked]>; "[email-masked]" <[email-masked]>; Ron Bonica <[email-masked]> 
>Sent: Wednesday, 8 August 2012 3:33 PM
>Subject: Re: [v6ops] Two prefixes [draft-ietf-v6ops-icp-guidance WGLC]
> 
>
>On Tue, Aug 7, 2012 at 10:42 PM, Brian E Carpenter <[email-masked]> wrote:
>
>If I were a content provider, I would think twice before choosing an architecture that breaks TCP connections when upstreams go down.

Stateful LBs and NPTv6s also performing stateful payload address translation (e.g. because TCP sequence numbers have to be bumped) going down would also be similarly disruptive to TCP connections wouldn't they?

NPTv6 is better than traditional IPv4 NAPT because the address translation in the IPv6 headers is stateless, however translating addresses in application payloads may not be, and your NPTv6 devices also then have to be application protocol aware, creating constraints if you want deploy new application protocols. My experience on the residential eyeball side of IPv4 load balances and the troubleshooting problems they've caused me or workarounds I've had to deploy at the network layer makes me hope they'll be far less common in IPv6.

Regards,
Mark.

---

From: Gert Doering <[email-masked]>
Date: Wed, 8 Aug 2012 13:28:26 +0200

Hi,

> architecture that breaks TCP connections when upstreams go down.

So you'll not use anything BGP based, then?

(Upstreams going down usually lead to transient loops and ICMP unreachables,
and those usually kill TCP sessions, at least if Windows stacks are 
involved)

Dual-/48 + shim6 actually reconverges *faster* on outage than anything
BGP based.  Just sayin'

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Aug 2012 13:12:23 +0100

> architecture that breaks TCP connections when upstreams go down.

Yes, and that certainly deserves a warning in the text.

My concern here, as I've already hinted, is publishing advice that is
valid for the N thousand enterprises that can reasonably expect to get
a PI prefix but nothing for the N million others that may wish to serve
up content *and* be multihomed.

   Brian

---

From: Arturo Servin <[email-masked]>
Date: Wed, 8 Aug 2012 11:59:29 -0300

Brian,

	But we are not talking about enterprises, we are talking about ICPs, which IMHO are two different problems and advices.

	For Enterprises, yes PA and PI are debatable (as discussed in many places, many times) and more dependent on the size and type of enterprise, for ICPs I think we are more or less in consensus that PI is more much common (and IMO the recommendation).

	Perhaps, the corner case are "small ICPs" which if they are uni-homed, then PA is fine, if they are multi-homed then BGP+PI should be the recommendation no matter if they are small or large.

Regards,
as

---

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

> 	But we are not talking about enterprises, we are talking about ICPs, which IMHO are two different problems and advices.

To be clear, I intended to talk about either pure specialised ICPs, or an enterprise that
wishes to behave as an ICP for its own content.

> 	Perhaps, the corner case are "small ICPs" which if they are uni-homed, then PA is fine, if they are multi-homed then BGP+PI should be the recommendation no matter if they are small or large.

But that's the case that doesn't scale to millions. Are you suggesting that
we have to tell them "you can't serve your own content reliably, because
you're too small"?

    Brian

---

From: Arturo Servin <[email-masked]>
Date: Wed, 8 Aug 2012 12:28:52 -0300

No, I didn't say that.

	1) if you are small, multi-homed you should use BGP+PI.

	2) if you are small and uni-home use PA.

	If 1 does not scale (I would question that), it is a problem that we should solve elsewhere.

	There are other solutions for 1, but I would not recommend them as a best practice, just like workarounds to use PA and avoid BGP.

	1 and 2 are orthogonal to the fact that the ICP is as well an enterprise or not.

Regards,
as

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Aug 2012 16:48:13 +0100

Arturo,

> 	If 1 does not scale (I would question that), it is a problem that we should solve elsewhere.

Yes, of course, and that was the main focus of the Routing Research Group for
a couple of years (see RFC 6115). It's pretty clear that it doesn't scale to
millions of sites with currently deployable technology. That being so,
IMHO v6ops has to be cautious about encouraging widespread usage. (This
applies generally, not just to ICPs, of course.)

   Brian

---

From: Erik Nygren <[email-masked]>
Date: Wed, 8 Aug 2012 20:29:50 -0500

I took a pass through this draft and had enough suggestions that
it was easiest to just pass them along as a patch/diff against the
-02.xml source
(see attached).

In general this feels like it will be very useful as a starting points
for people
at Internet content and application providers looking to kick off an
IPv6 effort.
As discussed on some of the other threads, I think its important that we
keep this focused on recommendations that will be useful to people
implementing IPv6 today, rather than on technologies that are still
under development.

Some of the proposed changes include:

* Proposed some compromise text in the "IPv6 Infrastructure" section
  on the PI vs PA address space topic discussed in the other thread.
  It feels like we should be giving concrete recommendations that are
  useful to ICPs now, but while still leaving doors open for the
  future.

* Add a note that support operations and support staff will generally
  also need to have IPv6 connectivity provisioned.  (Outside of universities,
  external server and staff network connectivity and environments are
often independent.)

* Renamed the "Proxy" section to "Surrogate" as what is being described
  there is explicitly a reverse proxy (surrogate) setup.

* Added more context and details and gotchas to the "DNS" section.
  This seems to be one of the top areas where ICPs seem to get
  themselves in trouble (perhaps because it seems like it's
  a "just do it").

* Added some notes on security (such as for host and network device
  firewalls) at appropriate points in the doc as ICPs especially
  shouldn't be thinking of these as an afterthought.

* Added some more notes into the Application Layer section,
  such as some particular notes about logging and testing,
  as this seems to be another area where things are often missed.

* Split up the CDN section into a broader section on "Complex Sites
  and Applications".  About half of the existing CDN section was more generally
  applicable to ICPs with multiple POPs, so "Distributed Locations"
  got its own subsection here.  I also added a subsection on
  "embeded resources" reminding ICPs to check that a rich
  site has more than just the base page available over IPv6.
  (I also took out the reference to my employer
  as that quote was from a few years ago and may not
  be generally helpful.)

* Fixed some typos and made a few other edits, as well as
  some others that I may have missed in the summary above.

I hope this is useful to folks.  I'm happy to discuss any
of my proposed changes in more detail.

  Erik

---------------------

All opinions expressed herein are my own and my not reflect those of
my employer.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 9 Aug 2012 06:52:00 +0000

Support this draft forward.

Some comments:

In section 4 "Arranging IPv6 Connectivity"
> There are, in theory, two ways to obtain IPv6 connectivity to the Internet. ... Native...Tunnel...
Although double translation doesn't concern ICPs, maybe it's better to mention it ? Since there might be confusion that translation was just missed to be considered.

In section 5.1, the last paragraph
We have two auto-config methods(DHCP/SLAAC) in IPv6, which is one of the most significant differences between IPv4. So, it may be worth to mention the DHCP/SLAAC co-existence issue. The issue has been documented by [RFC5887] and [6reum-gap-analysis], which could be references.

In section 12, second paragraph
> There is significant overlap here with the tools involved in site renumbering [I-D.jiang-6renum-enterprise].
[6renum-enterprise] only mentioned the tool, a brief detailed discussion about IPAM tool was in [6renum-gap-analysis], however, it may not be sufficient for OAM consideration. Maybe just simply deleting the reference is better.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Aug 2012 09:23:17 +0100

Erik,

Thanks for the careful review. You raise some good points but we will
have to analyse your proposed changes carefully before replying in detail.

Regards
   Brian