Subject: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance

From: <[email-masked]>
Date: Sat, 22 Oct 2011 06:55:00 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance. Please take a look at it and comment.

---

From: John Mann <[email-masked]>
Date: Mon, 24 Oct 2011 09:01:39 +1100

Hi,

On 23 October 2011 00:55, <[email-masked]> wrote:

>
> A new draft has been posted, at
> http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance. Please take
> a look at it and comment.
>

---
12. Security Considerations

... it is advisable to block incoming IPv4-in-IPv6
tunnel traffic using IPv4 protocol type 41.
---
s/IPv4-in-IPv6/IPv6-in-IPv4/

===

---

1.  Introduction

   The deployment of IPv6 [RFC2460
<http://tools.ietf.org/html/rfc2460>] is now in progress, and users
with
   no IPv4 access are likely to appear in increasing numbers in the
   coming years. ...

---

I am not sure that we will see normal Internet users with *no* IPv4 access
any time soon.
ISPs and users acting in their own local best interest will stop that from
happening.
I think it is likely that
a) ISPs will deploy NAT4...4 , and/or
b) ISPs will deploy Web proxies, and/or
c) users will seek out public proxies that can do IPv6->IPv4, and finally
d) some special-purpose networks will be created from where IPv4 access is
not required

I would prefer the document to use a different term, e.g. IPv4-impaired
users,
where this means someone whose IPv4 Internet access is degraded by NAT or
proxies
and their IPv6 network experience is better than over IPv4.

===

Re Sections 3 and 5.1 can some mention be made about avoiding IPv4-think ??
IPv4 and IPv6 should not be thought of as the same.
For example: the need to micro-manage addresses v. address abundance,
obscurity through NAT v. stateful firewalls,
fragmentation in routers v. end-systems
ICMPv6 [ as discussed in Sec 9 and 12 ]
...

===

Re Section 5.1, I'm using SLAAC for end-user machines, and statically
configured IPv6 addresses for servers and network equipment -- which has
worked quite well so far.
DHCPv6 clients aren't available and deployed everywhere yet.

======================

And now, some suggested additions to the document ...

===
At around section 5.2, I would add

5.x Network Clean-up

It is highly likely that there are sub-optimal parts of your network
configuration, IPv4 address plan, network management systems, procedures,
etc.
If you just add IPv6 on top, the network will become more complicated and
harder to manage.

Take the opportunity to clean up some sub-optimal parts of your IPv4
network, and come up with a better combined IPv4 and IPv6 network design,
better standards, tools and procedures.  Use the one set of tools to manage
and monitor IPv4 and IPv6.

5.x Common Topology

To avoid increasing complexity, use common IPv4 and IPv6 infrastructure as
much as possible.
Sending IPv4 and IPv6 traffic over the same path helps both avoid and debug
network problems.
Having the one firewall, IPS or load balancer handle IPv4 and IPv6 increases
the chance that the box will be configured to do similar things with both
protocols.

===
5.3 DNS

Apart from the service address published for clients to connect to, a host
will have several other IPv6 addresses - Link-Local, SLAAC, Privacy, ...
To help identify network traffic, it is very useful to have all these other
addresses in whatever IPAM system you are using, and optionally put into the
reverse DNS.

===
6 Load Balancers

Some load balancers can do IPv6->IPv6, and some can do IPv6->IPv4 network
protocol translation.
The latter is a useful interim solution, but has the reverse-proxy caveats
listed in Sec 7.

===
7 Proxies

     "Reverse Proxies" rather than "Proxies" ??

Note that a Reverse Proxy forwards all traffic to the HTTP server from the
proxy's IPv4 address.
This hides the true network address of the client from the IPv4 HTTP server
unless the proxy adds an extra header to the HTTP request, and the HTTP
server acts on the extra header.

Having all traffic come from the one IPv4 address can disrupt IPv4
Geolocation (different problem from Sec 8.3), IPv4-based access controls,
IPv4-based cookies, IPv4-based DDoS prevention [ref IPv6 day report],
IPv4-based log analysis, etc

===

Thanks,
    John

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Wed, 26 Oct 2011 13:08:38 +0300

Hi,

I have some comments+corrections about draft-carpenter-v6ops-icp-guidance-00:

The purpose of this document is to provide guidance and suggestions
for Internet Content Providers (ICPs) and Application Service
Providers (ASPs) who wish to offer their service to both IPv6 and
IPv4 customers.

Since the focus is mostly in IPv6

The purpose of this document is to provide guidance and suggestions
for Internet Content Providers (ICPs) and Application Service
Providers (ASPs) who wish to offer their service to IPv6 customers,
besides their IPv4 customers.

This is by far the better method

better => best

5.1. Address and subnet assignmen

However, the
wide area routing system (BGP4) can only support a limited number of
routes for PI prefixes, so only the largest providers can justify the
bother and expense of obtaining a PI prefix and convincig their ISPs
to route it.

Maybe i don't understand the exact meaning, but can you please
explain why "BGP can only support a limited number of routes of PI
prefixes"?

Also "convincig" => "convincing"

An ICP that has multiple connections via multiple ISPs will have
multiple PA prefixes. This commonly results in multiple PA-based
addresses for the servers.

Is this common practice? Using multiple addresses (each from a
different prefix/ISP) on servers?

I though this was happening on the front-end (i.e LB) devices.

Theoretically, it would be possible to operate an ICP's IPv6 network
using only Stateless Address Autoconfiguration [RFC4862]. In
practice, an ICP of reasonable size will probably choose to operate
DHCPv6 [RFC3315] and use it to support stateful and/or on-demand
address assignment.

Is any ICP really using SLAAC? Static should probably be the first
choice, with DHCPv6 being the 2nd (when clients become more common).

I know for sure, that although we are not strictly an ICP, all the
devices/servers that are being used for content distribution are
with static addresses.

One important detail is that some clients (especially
Windows XP) can only reslove DNS names via IPv4, even if they can use
IPv6 for application traffic.

reslove => resolve

As far as possible, however, mutual dependency between IPv4 and IPv6
operations should be avoided. A failure of one should not cause a
failure of the other. One precaution to avoid this is that back-end
systems such as network management databases should themselves be
dual stacked. It should be possible to use IPv4 connectivity to
repair IPv6 configurations, and vice versa.

Although i would like very much to do this, i don't think this (i'm
referring to back-end systems) is quite applicable today or in the
near future. Changing the back-end systems to dual stack is probably
our last priority.

We already use the reverse of "IPv4 connectivity to repair IPv6
configurations" for our routers mostly in cases of a IPv4 mw, but
for servers and generally back-end systems it seems a little bit
strange.

Maybe change "should" to "could"?

One precaution to avoid this is that back-end
systems such as network management databases could themselves be
dual stacked. That way it could be possible to use IPv4 connectivity to
repair IPv6 configurations, and vice versa.

In some cases, clients may reach an ICP service via a network-layer
translator between IPv4 and IPv6. ICPs who are offering a dual stack
service, as recommended in this document, should not normally see
traffic from NAT64 translators [RFC6146]. Exceptionally, such
traffic could arrive via IPv4 from an IPv6-only client whose DNS
resolver failed to receive the ICP's AAAA record, but this would be
indistinguishable from a regular IPv4-via-NAT customer. Similarly,
ICPs who are offering a dual stack service might exceptionally see
IPv6 traffic translated from an IPv4-only client that somehow failed
to receive the ICP's A record. This would only be an issue if the
ICP was offering any service that depends on the assumption of end-
to-end IPv6 address transparency.

The above should probably be rewritten, because it refers to NAT64
and then it talks about "IPv6 traffic translated from an IPv4-only
client".

Just an idea...

In some cases, clients may reach an ICP service via a network-layer
translator between IPv4 and IPv6. ICPs who are offering a dual stack
service, as recommended in this document, should not normally see
traffic from any kind of IPv6 to IPv4 (like NAT64 [RFC6146])
or IPv4 to IPv6 translators. Exceptionally, IPv4 translated
traffic could arrive from an IPv6-only client whose DNS
resolver failed to receive the ICP's AAAA record, but this would be
indistinguishable from a regular IPv4-via-NAT customer, or
IPv6 translated traffic could arrive from an IPv4-only client that somehow failed
to receive the ICP's A record. This would only be an issue if the
ICP was offering any service that depends on the assumption of end-
to-end IPv6 address transparency.

If an ICP or ASP uses IPsec [RFC4301] and IKE [RFC5996] in any way to
secure connections with clients, these too are fully applicable to
IPv6, but only if the software stack at each end has been
appropriately updated.

IPsec/IKE are usually used by customers for management reasons. I
don't think normal clients, whose purpose is to get the content,
would use something like that.

Ok, i don't know if that is normal in ASPs.

--
Tassos

[email-masked]
wrote on 22/10/2011 16:55:

A new draft has been posted, at http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance. Please take a look at it and comment.
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Oct 2011 09:53:22 +1300

Tassos,

Thanks for commenting. Some responses in line below.

On 2011-10-26 23:08, Tassos Chatzithomaoglou wrote:
> The purpose of this document is to provide guidance and suggestions for Internet 
> Content Providers (ICPs) and Application Service Providers (ASPs) who wish to 
> offer their service to IPv6 customers, besides their IPv4 customers.

That's really a matter of taste, but I believe that since most of today's
business comes from IPv4 customers, the emphasis is on coexistence.

>> This is by far the better method

No, when comparing two alternatives, the correct English is "better".
"Best" is for three or more alternatives.

> Maybe i don't understand the exact meaning, but can you please explain why "BGP 
> can only support a limited number of routes of PI prefixes"?

There is an enormous literature on BGP4 scaling, so we can add a reference,
RFC 4984 or RFC 6227.

> Also "convincig" => "convincing"

Ack

> Is this common practice? Using multiple addresses (each from a different 
> prefix/ISP) on servers?

No. "Will" is the future tense. This is the standard model for IPv6.

>>    using only Stateless Address Autoconfiguration [RFC4862 <http://tools.ietf.org/html/rfc4862>].  In
>>    DHCPv6 [RFC3315 <http://tools.ietf.org/html/rfc3315>] and use it to support stateful and/or on-demand
>>    address assignment.
> 
> Is any ICP really using SLAAC? Static should probably be the first choice, with 
> DHCPv6 being the 2nd (when clients become more common).
> devices/servers that are being used for content distribution are with static 
> addresses.

That's why it says "theoretically". As for static, please have a look
at draft-carpenter-6renum-static-problem. We should probably refer to
renumbering challenges and dynamic DNS update here, too.

>>    IPv6 for application traffic.

Ack

> Although i would like very much to do this, i don't think this (i'm referring to 
> back-end systems) is quite applicable today or in the near future. Changing the 
> back-end systems to dual stack is probably our last priority.
> We already use the reverse of "IPv4 connectivity to repair IPv6 configurations" 
> for our routers mostly in cases of a IPv4 mw, but for servers and generally 
> back-end systems it seems a little bit strange.

In the long term, IMHO it should be "should", because otherwise you will be
running legacy junk for ever. It's a timing question, and it depends on size.
We can make it clear that "should" is the end goal, not the starting point.

[Example: we've been running our departmental HTTP servers as pure dual
stack for a couple of years, because they are simple and straightforward.
But the main University servers will no be dual stacked for quiet a while,
because they depend on other network elements such as load balancers that
need to be updated. So the plan is to provide IPv6 access via a reverse proxy
first. So we are doing both inside-out and outside-in on the same network.]
>>    traffic from NAT64 translators [RFC6146 <http://tools.ietf.org/search/rfc6146>].  Exceptionally, such
> The above should probably be rewritten, because it refers to NAT64 and then it 
> talks about "IPv6 traffic translated from an IPv4-only client".
> Just an idea...

Yes, it's confusing. Probably it should be two separate paragraphs, one for
NAT64 and the other for NAT46.

>    traffic from any kind of IPv6 to IPv4 (like NAT64 [RFC6146 <http://tools.ietf.org/search/rfc6146>])
>>    If an ICP or ASP uses IPsec [RFC4301 <http://tools.ietf.org/search/rfc4301>] and IKE [RFC5996 <http://tools.ietf.org/search/rfc5996>] in any way to
> IPsec/IKE are usually used by customers for management reasons. I don't think 
> normal clients, whose purpose is to get the content, would use something like that.

Yes, we can't really make general statements about ASPs. But I think IPsec is
probably never used by pure content providers.

Thanks!
   Brian

---

From: "Eleven Fu(Yu)" <[email-masked]>
Date: Fri, 28 Oct 2011 10:02:36 +0000

Hi Brian

 Some comments for draft-carpenter-v6ops-icp-guidance-00 as follows:

     o  Outside in: start by providing external users with an IPv6 public
        access to your services, for example by running a reverse proxy
        that handles IPv6 customers (see Section 7 for details).
        Progressively enable IPv6 internally.
     o  Inside out: start by enabling internal networking infrastructure,
        hosts, and applications to support IPv6.  Progressively reveal
        IPv6 access to external customers.

        Which of these approaches to adopt depends on the precise
        circumstances of the ICP concerned.  "Outside in" has the benefit of
        giving interested customers IPv6 access at an early stage, and
        thereby gaining precious operational experience, before meticulously
        updating every piece of equipment and software. For example, if some
        back-office system, that is never exposed to users, only supports
        IPv4, it will not cause delay.  "Inside out" has the benefit of
        completing the implementation of IPv6 as a single project.  Any ICP
        could choose this approach, but it might be most appropriate for a
        small ICP without complex back-end systems.

  In this section, it only analyze the benefit of the two approaches. I think it may be more useful to list the benefits, drawbacks, the cost for ICPs, influence to
  existing operations, and some other considerations for each approach respectively. So the ICPs could choose their specific strategy according to this section.

        4. Arranging IPv6 Connectivity

       There are, in theory, two ways to obtain IPv6 connectivity to the Internet.

       o  Native.  In this case the ISP simply provides IPv6 on exactly the
          same basis as IPv4 - it will appear at the ICP's border router(s),
          which must then be configured in dual-stack mode to forward IPv6
          packets in both directions.  This is by far the better method.  An
          ICP should contact all its ISPs to verify when they will provide
          native IPv6 support, whether this has any financial implications,
          and whether the same service level agreement will apply as for
          IPv4.  Any ISP that has no definite plan to offer native IPv6
          service should be avoided.
       o  Tunnel.  It is possible to configure an IPv6-in-IPv4 tunnel to a
          remote ISP that offers such a service.  A dual-stack router in the
          ICP's network will act as a tunnel end-point, or this function
          could be included in the ICP's border router.

  What about translation? For example, double translation?

        However, the wide area routing system (BGP4) can only support a limited number of
        routes for PI prefixes, so only the largest providers can justify the bother and expense
        of obtaining a PI prefix and convincig their ISPs to route it.

  In this sentence, convincig--->convince

Cheers

Yu

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Fri, 28 Oct 2011 16:37:14 +0300

Hi Brian,

> There is an enormous literature on BGP4 scaling, so we can add a reference,

I've known of these discussions for years, but i believe making such a "worrying" 
reference here isn't quite right.
After all, another BCP (draft-ietf-idr-deprecate-as-sets) proposes to announce the more 
specifics of the previously aggregated prefix, in order to "solve" a future problem.
I'm not saying that this is not an issue in general, i'm just saying that the absolute 
statement "BGP can only support a limited number of routes of PI prefixes" leaves a lot to 
be discussed.

>>>     using only Stateless Address Autoconfiguration [RFC4862<http://tools.ietf.org/html/rfc4862>].  In
>>>     DHCPv6 [RFC3315<http://tools.ietf.org/html/rfc3315>] and use it to support stateful and/or on-demand
>>>     address assignment.
Ok, but how ofter do you do renumbering? ...especially in an ICP.

Generally, i'm getting the impression of focusing more on enterprise-style ICPs and less 
on service-provider-style ICPs or just ICPs.
Ok, these are terms i just invented now, but i'm thinking that some things in this draft 
are mostly tailored for enterprises (or campuses?) that just happen to offer public 
content too.

Thanks
Tassos

---

From: "George, Wes" <[email-masked]>
Date: Fri, 28 Oct 2011 12:52:40 -0400

I'm somewhat disinclined to see this one adopted/discussed based on an initial scan of it.

No offense intended against the authors, because I think that content-wise the document is good, but I really feel like we've done this before... a lot.
We have documents covering each of the 6,245 permutations of IPv4/IPv6 transition technologies; pros, cons, gaps, traps, and maps ("overviews" doesn't fit my Suessian rhyme scheme). We're down to a second or third level of recursion where we need a survey of the survey documents just to keep track of where the useful info might be found. We seem to be trying to speed deployment by burying our supposed audience in "paper" as if the real problem is that people simply don't know how to do it.

At this point, I'd really rather see people (operators) coming forward with cases that they think are not covered and requesting that Those Who Know About These Things oblige them with some sage advice. I'm simply not convinced that any more unsolicited documents about how to deploy IPv6 are doing anyone any good, no matter how well-written they are.

I want to keep an open mind, so I invite the authors (or members of the intended audience of ICPs) to identify the reasons why this particular draft is necessary, where the current voluminous body of documents about deploying IPv6 are inadequate or incomplete.

Thanks
Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Saturday, October 22, 2011 9:55 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance
>
>
> A new draft has been posted, at http://tools.ietf.org/html/draft-
> carpenter-v6ops-icp-guidance. Please take a look at it and comment.

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Fred Baker <[email-masked]>
Date: Fri, 28 Oct 2011 09:57:59 -0700

On Oct 28, 2011, at 6:37 AM, Tassos Chatzithomaoglou wrote:

> I'm not saying that this is not an issue in general, i'm just saying that the absolute statement "BGP can only support a limited number of routes of PI prefixes" leaves a lot to be discussed.

Chair hat off...

The fact that BGP today carries ~400K prefixes tells me that any worries we have about it being *able* to carry prefixes are unfounded. The question that I think Brian in fact wants to ask here is whether enumerating the network edge, as opposed to the access and transit networks the edge connects to, is a desired state.

The whole premise behind shim6 (which Brian has contributed to, and which presumes that every LAN in an edge network will have a subnet from every upstream ISP, and as a result every host interface will sport multiple addresses) is that PA addressing will be used to limit the size of the route table. The premise behind NPTv6 is that an edge network can be PI from its own perspective and PA from the perspectives of its various upstreams, limiting the size of the route table while limiting edge network complexity. In both cases, the idea is to reduce ISP opex and capex (memory, heat, power, ...) by not forcing them to carry large numbers of PI routes.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Oct 2011 10:21:07 +1300

Tassos,

On 2011-10-29 02:37, Tassos Chatzithomaoglou wrote:
>>> explain why "BGP
> I've known of these discussions for years, but i believe making such a
> "worrying" reference here isn't quite right.
> After all, another BCP (draft-ietf-idr-deprecate-as-sets) proposes to
> announce the more specifics of the previously aggregated prefix, in
> order to "solve" a future problem.
> I'm not saying that this is not an issue in general, i'm just saying
> that the absolute statement "BGP can only support a limited number of
> routes of PI prefixes" leaves a lot to be discussed.

Indeed it does. I agree that this should be rephrased in the next version.

>>>>     using only Stateless Address Autoconfiguration
>>>> [RFC4862<http://tools.ietf.org/html/rfc4862>].  In
>>> choice, with

That depends on the size of the ICP. However, this discussion
probably belongs in the 6renum WG.

> 
> Generally, i'm getting the impression of focusing more on
> enterprise-style ICPs and less on service-provider-style ICPs or just ICPs.
> Ok, these are terms i just invented now, but i'm thinking that some
> things in this draft are mostly tailored for enterprises (or campuses?)
> that just happen to offer public content too.

Yes, I agree. The vast majority of content providers are indeed enterprise
and campus networks, not Google, Yahoo and so on. It's unfortunate
that those mid-size and small ICPs are not very present in v6ops.

(Most of them use load balancing techniques, too, which is why we
tagged draft-carpenter-v6ops-label-balance for this WG.)

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Oct 2011 10:31:13 +1300

Wes,

> At this point, I'd really rather see people (operators) coming forward with cases that they think are not covered 

The intended audience for this draft is ICPs *of all sizes* (see my reply
just sent to Tassos) and they are definitely under-represented in v6ops,
so it's no surprise that we don't see them coming forward with problems.
The really big ICPs don't need this advice - in fact they should be
writing it, ideally. The mid-size and smaller ICPs are just coming to
consciousness of the fact that they need to plan for coexistence - shouldn't
we be anticipating this?

We looked at the existing RFCs on enterprise deployment of IPv6 and did
not find any guidance for ICPs and ASPs. It isn't really a question of
describing yet more permutations - my personal preference is to
describe as few permutations as possible.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Oct 2011 10:35:53 +1300

> The whole premise behind shim6 (which Brian has contributed to, and which presumes that every LAN in an edge network will have a subnet from every upstream ISP, and as a result every host interface…

Exactly. To rehash an old argument from the RRG, if we end up with ten million
enterprise networks all wanting their own BGP4 route, we probably have a problem,
but if we only end up with a million or so BGP4 routes, we are probably OK.

As I wrote a few minutes ago, we will improve the text in the draft.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Oct 2011 10:44:19 +1300

Thanks Yu, see in line...

>   existing operations, and some other considerations for each approach respectively. So the ICPs could choose their specific strategy according to this section.

Agreed that more discussion of pros and cons might help.

>   What about translation? For example, double translation?

Double translation doesn't concern ICPs; it's a solution for ISPs
who don't want to run dual stack routing.

My *personal* opinion that we should not encourage ICPs to rely
on NAT64 or any variant of it. It provides degraded service and dual
stack is easier and more reliable. I suppose it could be part of an
outside-in strategy, but a dual stack proxy is a cleaner solution
(for an HTTP/S service).

Thanks
    Brian

---

From: Doug Barton <[email-masked]>
Date: Fri, 28 Oct 2011 17:27:02 -0700

> outside-in strategy, but a dual stack proxy is a cleaner solution

Overall I agree. I've been saying for a long time that the likely
migration scenario for the next 5 years or so (call it "near term
plus?") is some form of native IPv6 and native IPv4 to the border. For
those with PI space the same native IPv6 block will likely go through
the border into the enterprise network. For those with PA space I'm
thinking (and this is an area I'm less certain about, but I think it's
likely) is some form of ULA inside, and 6296 on the border. Same goes
for IPv4. PI space will almost certainly continue to be deployed as it
is today, and NAT+1918 will almost certainly continue to be the answer
for those who are already using it.

The interesting parts of the equation come down the road when IPv4
becomes prohibitively expensive to obtain. (Note, I'm carefully avoiding
the term "runs out") :)  At that point things become interesting, and
something like NAT64 is likely to be necessary, although I'm dubious
about the current deployment concept. I think it's far more likely that
"regular" NAT will continue will continue to operate on the interior of
the network, and that the NAT64'ish bits will happen at the border, but
I reserve the right to be wrong about that.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Fred Baker <[email-masked]>
Date: Sat, 29 Oct 2011 12:51:36 -0700

On Oct 28, 2011, at 5:27 PM, Doug Barton wrote:

> At that point things become interesting, and something like NAT64 is likely to be necessary, although I'm dubious about the current deployment concept.

Are you referring to 

http://tools.ietf.org/html/draft-sunq-v6ops-contents-transition
  "Rapid Transition of IPv4 contents to be IPv6-accessible", Qiong Sun,
  Chongfeng Xie, Qian Liu, Xing Li, Jacni Qin, Dong Liu, Qin Zhao,
  29-Oct-11

?

---

From: Joel jaeggli <[email-masked]>
Date: Sat, 29 Oct 2011 21:46:34 -0700

On 10/28/11 14:31 , Brian E Carpenter wrote:
> Wes,
> 
>> At this point, I'd really rather see people (operators) coming
>> forward with cases that they think are not covered
> 
> The intended audience for this draft is ICPs *of all sizes* (see my
> reply just sent to Tassos) and they are definitely under-represented
> in v6ops, so it's no surprise that we don't see them coming forward
> with problems. 

One of the chairs, a content provider...

Google is here, Facebook is here, Yahoo, is here, Microsoft is here
Apple is here. I get the impression that several Weibo are here...

> The really big ICPs don't need this advice - in fact
> they should be writing it, ideally.

Dual stacking a content provider to the extent that is necessary to
provide IPv6 services turns out to not be very hard. Deciding when and
how to enable AAAA records for given service causes more existential
ennui than whacking a v6 address on the outside of an
a10/f5/ha-proxy/nginx, that party of the reason Jason's draft got as
much commentary as it did.

> The mid-size and smaller ICPs are
> just coming to consciousness of the fact that they need to plan for
> coexistence - shouldn't we be anticipating this?

> We looked at the existing RFCs on enterprise deployment of IPv6 and
> did not find any guidance for ICPs and ASPs. It isn't really a
> question of describing yet more permutations - my personal preference
> is to describe as few permutations as possible.
> 
> Regards Brian
> 
>> No offense intended against the authors, because I think that
>> content-wise the document is good, but I really feel like we've
>> done this before... a lot. We have documents covering each of the
>> 6,245 permutations of IPv4/IPv6 transition technologies; pros,
>> cons, gaps, traps, and maps ("overviews" doesn't fit my Suessian
>> rhyme scheme). We're down to a second or third level of recursion
>> where we need a survey of the survey documents just to keep track
>> of where the useful info might be found. We seem to be trying to
>> speed deployment by burying our supposed audience in "paper" as if
>> the real problem is that people simply don't know how to do it.
>> 
>> At this point, I'd really rather see people (operators) coming
>> forward with cases that they think are not covered and requesting
>> that Those Who Know About These Things oblige them with some sage
>> advice. I'm simply not convinced that any more unsolicited
>> documents about how to deploy IPv6 are doing anyone any good, no
>> matter how well-written they are.
>> 
>> I want to keep an open mind, so I invite the authors (or members of
>> the intended audience of ICPs) to identify the reasons why this
>> particular draft is necessary, where the current voluminous body of
>> documents about deploying IPv6 are inadequate or incomplete.
>> 
>> Thanks Wes George
>> 
>> 
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of [email-masked] Sent:
>>> Saturday, October 22, 2011 9:55 AM To: [email-masked] Cc:
>>> [email-masked] Subject:
>>> [v6ops] new draft: draft-carpenter-v6ops-icp-guidance
>>> 
>>> 
>>> http://tools.ietf.org/html/draft- carpenter-v6ops-icp-guidance.
>>> Please take a look at it and comment. 
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> This E-mail and any of its attachments may contain Time Warner
>> Cable proprietary information, which is privileged, confidential,
>> or subject to copyright belonging to Time Warner Cable. This E-mail
>> is intended solely for the use of the individual or entity to which
>> it is addressed. If you are not the intended recipient of this
>> E-mail, you are hereby notified that any dissemination,
>> distribution, copying, or action taken in relation to the contents
>> of and attachments to this E-mail is strictly prohibited and may be
>> unlawful. If you have received this E-mail in error, please notify
>> the sender immediately and permanently delete the original and any
>> copy of this E-mail and any printout. 
>> _______________________________________________ v6ops mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Joel jaeggli <[email-masked]>
Date: Sat, 29 Oct 2011 22:07:47 -0700

> who don't want to run dual stack routing.

just puts us one step futher away from the customers source ip address...

>>   In this sentence, convincig--->convince

multihoming is not expensive/bothersome because of the finite size of
the routing table...

it is expensive/bothersome because it implies:

	relationship with two or more isps
	relationship with an rir/lir
	dedicated infrastructure (e.g. rackspace,port charges, power
	etc)
	routing clue.

It is it should be noted dramatically cheaper for a modest capacity edge
network to carry the whole routing table than it is for a large network,
so route count really is not a consideration.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Oct 2011 09:10:20 +1300

Joel,

> multihoming is not expensive/bothersome because of the finite size of

Not for the site concerned or even for its Tier 3 ISPs, indeed. But it's
an externality cost that the site and its ISPs impose on all Tier 1 and 2
ISPs, and that should be our concern.

> 	relationship with two or more isps

Sure, two contracts.

> 	relationship with an rir/lir

Not if you use PA.

> 	dedicated infrastructure (e.g. rackspace,port charges, power

Correct, but that's unavoidable. Of course we should strive to reduce the
amount of routing clue needed; it's off-topic, but the long term goal
should surely be to extend homenet-style solutions to small and medium
enterprises too.

> so route count really is not a consideration.

Not for the edge network, but it exports the externality cost upstream.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Oct 2011 09:13:59 +1300

> Apple is here. I get the impression that several Weibo are here...

Agreed - it's the campus-sized and smaller ones that we don't hear
much from.

> provide IPv6 services turns out to not be very hard. 

It's not hard but the people who need to do it need guidance to get
started. I speak from experience.

   Brian

> Deciding when and

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Oct 2011 09:21:22 +1300

>   Chongfeng Xie, Qian Liu, Xing Li, Jacni Qin, Dong Liu, Qin Zhao,

That is a very different deployment model than draft-carpenter-v6ops-icp-guidance
advocates. I can understand that there might be unusual circumstances in which
it would be chosen, but it is so much simpler to dual-stack all servers.

   Brian

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 30 Oct 2011 15:42:50 -0700

> ISPs, and that should be our concern.

I'm not sure I agree, but in any event, that's not what the text says.

Stewardship of the resource if multihoming is a requirement, would be
injecting the minimum number of routes necessary to achieve your
business objective and not more.

>> 	relationship with an rir/lir

If it's PA your provider is likely operating in their capacity as an
LIR. you're going want an asn in any event which they can also provide.

> Correct, but that's unavoidable.

Some rather large content providers run on virtualized infrastructure,
that they pay for based on usage and have no physical footprint. So I
wouldn't go that far. It's pretty trivial to do in the small to medium
scale space. it tends to imply today that you're using the cloud
provider(s) numbering resources

> Of course we should strive to reduce the

An enterprise of the traditional sort, that is one with a physical
location, has in general a facilities problem, e.g. the have locations,
or at least things to network. in the icp case, what exists in the real
would does so to support the application not the other way around.

...

---

From: "George, Wes" <[email-masked]>
Date: Mon, 31 Oct 2011 10:27:35 -0400

> From: Brian E Carpenter [mailto:[email-masked]]
> Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance
>
> Wes,
>
> reply just sent to Tassos) and they are definitely under-represented in
> v6ops, so it's no surprise that we don't see them coming forward with
> problems.
> consciousness of the fact that they need to plan for coexistence -
> shouldn't we be anticipating this?

[WEG] Ok, but the two statements above somewhat conflict with one another. If it's guidance for all sizes, that sort of asserts that at least some of the large ones need it or find it useful. It may be that the guidance is simply one-size-fits-all, and that's probably ok with some clarification text. But If you agree that the larger ICPs don't really need this document, then it might make sense to more tightly scope your draft and focus on the things that actually are different. However, if ICPs on the smaller side are not being represented here, do you really think that they're more likely start their quest to figure it out by looking here, or to one of the eleventy-two Wikis, vendor whitepapers and other prior art (see below) on the matter that are less static than an IETF draft?

> not find any guidance for ICPs and ASPs.

[WEG]] I don't think I need to provide references, but I wouldn't limit my search to RFCs. One can look at the agenda records for any NANOG, RIR, or IPv6-related conference in the last several years to find good coverage from a number of the aforementioned larger ICPs explaining that this isn't hard, and how to do it, considerations, etc. Joel's mention of the whitelisting implications draft makes me think that perhaps a reference to that would be helpful for your draft as well. As above, if there are things that are unique to smaller applications, focus on those, but don't retread those that are common.

Thanks
Wes