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

From: John Mann <[email-masked]>
Date: Mon, 5 Mar 2012 15:23:56 +1100

Hi,

---

   An important first step in every strategy is to determine from every
   hardware and software supplier details of their planned dates for
   providing full IPv6 support, with performance equivalent to IPv4, in
   their products and services.
---
I disagree with this being a _first_ step.
Asking _every_ hardware and software supplier can take a lot of time and effort,
and can lead to ICP in-action e.g. if some suppliers are not ready.

Also, "full IPv6 support" can be hard to specify and evaluate -- do
you mean comply with all RFCs,
pass specific certification tests, or just the specific list of
features that you use with IPv4?

My alternate view is

a) Make a policy decision to avoid the creation of any new
customer-facing networks or services that are IPv4-only
b) Enable IPv6 on what you already have, with perhaps some tactical
expenditure to:
   i) get some IPv6 traffic flowing

   ii) start work on the sections described below e.g. external
connectivity, address plan, training, operations, and security.
   iii) get the first IPv6 service operational
c) Build on the experience and success of the first service to plan
and justify subsequent IPv6 steps.

d) Triage your hardware and software
   i) legacy internal IPv4-only systems that don't ever need to support IPv6
   ii) systems that can already support IPv6
   iii) systems due to be replaced soon -- by systems that will
support IPv6 (see (a) above)

   iv) systems that will require extra effort or expenditure to get IPv6 support
   v) problem systems -- e.g. none of the possible suppliers have an
IPv6 roadmap.

====

I think some mention could be made in

   5.2. Routing
that running dual-stack could require twice the routing table space
and forwarding TCAM in the routers

And in
   13. Security Considerations
that running dual-stack could require twice the amount of permission
lists, ACLs, TCAMs etc.

The growth in table size hopefully won't be 5 times (32 bits to 32 + 128 bits),
due to most IPv6 routing only going down to /64s, fewer IPv6 routes,
shorter history of IPv6 exceptions, etc.

Thanks,
    John

On 23 February 2012 14:41, Brian E Carpenter <[email-masked]>wrote:

> Hi,
>
> This version has various updates due to comments from the WG.
>
> We are not asking for a meeting slot in Paris, but we'd like the
> chairs to put the question whether the WG wants to adopt this
> draft. In any case we still want more input to correct and
> expand the draft.
>
>    Brian + Sheng
>
> -------- Original Message --------
> Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt
> Date: Wed, 22 Feb 2012 14:30:09 -0800
> From: [email-masked]
> Reply-To: [email-masked]
> To: [email-masked]
>
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
>
>        Title           : IPv6 Guidance for Internet Content and
> Application Service Providers
>        Author(s)       : Brian Carpenter
>                          Sheng Jiang
>        Filename        : draft-carpenter-v6ops-icp-guidance-03.txt
>        Pages           : 18
>        Date            : 2012-02-22
>
>   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 any enterprise network preparing for IPv6 users.
>
>
> A URL for this Internet-Draft is:
>
> http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
>
> ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announce%0AInternet-Draft>directories:
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Mar 2012 09:47:01 +1300

Hi John, thanks for the review,

> I disagree with this being a _first_ step.

Personally I disagree, but it's certainly a debatable point and I'd
like to hear from other people. My experience with IT managers is that
they hate surprises, and discovering late in the game that a key component
doesn't work is the worst kind of surprise.

> and can lead to ICP in-action e.g. if some suppliers are not ready.

Correct. I would certainly modify the statement to refer specifically to
determining critical path items - but your exact deployment plan might
change according to which components will be available when.

> features that you use with IPv4?

That is very variable. Enterprises labouring under some stupid set of
auditable requirements might have to be very strict; others might be
very pragmatic. Either way, the criterion is functionality needed
for IPv6, not an IPv4-driven feature list. I agree that this should
be more carefully phrased.

>    i) get some IPv6 traffic flowing

What traffic? There won't be any revenue-generating traffic unless
you make the user-facing service support IPv6.
> and justify subsequent IPv6 steps.

That's not very different from what the draft proposes.
>    v) problem systems -- e.g. none of the possible suppliers have an

You should certainly do all that; I don't understand how it can be done at
the end.

> and forwarding TCAM in the routers

Well, more space, indeed.

> that running dual-stack could require twice the amount of permission

Yes, which is why a lot of people want feature-equivalence, so that
they only have to maintain a single config to drive both protocols.

> shorter history of IPv6 exceptions, etc.

Agreed

    Brian

---

From: John Mann <[email-masked]>
Date: Tue, 6 Mar 2012 09:32:02 +1100

Hi,

> doesn't work is the worst kind of surprise.

Yes, late surprises are bad.
My view is to start trying to use IPv6 as early as possible so that you can
discover early the things that don't work (the way you expected them to).

IPv6 is different enough that there will be things that you know you need
to plan for,
and other things that you *don't know* that you have to deal with until
after you have completed the previous steps.

> change according to which components will be available when.

May I suggest -- several deployment phases, each of which will have
critical path items that will need IPv6 support.

> you make the user-facing service support IPv6.

Sorry, I wasn't implying revenue-generating user-facing IPv6 traffic.

I just meant _some_ IPv6 traffic -- preferably communicating with the IPv6
Internet.
It could be as simple as dual-stacking a test FTP server in the DMZ.
Or IPv6-enabling a test user subnet.  It doesn't matter if it is only 100
packets per day!

My point was that once you have _some_ IPv6 traffic, it enables the
following steps.
IPv6 has become tangible, it is no longer hypothetical.

Getting the first bit of IPv6 working can also dispel FUD.
It shows that adding IPv6 doesn't cause the world to end, that IPv4 and
IPv6 are ships-in-the-night protocols.

> That's not very different from what the draft proposes.

Agreed.

> > shorter history of IPv6 exceptions, etc.

Another issue is mentioned in several places in the draft, but I didn't see
it pulled together in one spot:
For tactical reasons it may be necessary to use different infrastructure to
support IPv6 than IPv4,
but there are major advantages in simplicity and maintainability if shared
common infrastructure can be used for
ISP links, routers, firewalls, load balancers, web servers, network
monitoring, security management, IPAM etc

    John

   Brian
> >> Internet-Draft<
> https://www.ietf.org/mailman/listinfo/i-d-announce%0AInternet-Draft
> >directories:

---

From: Hui Deng <[email-masked]>
Date: Sun, 11 Mar 2012 23:35:14 +0800

Hi Authors,

I have several comments about this draft:
1) do you want to classify different level of ICP, from the reading, this
document is targetting at
the ICP who are not faimliar with IPv6, but sometimes, ICP may deploy their
server in some IDC or some may
be based on their own location, which may have different consideration;

2) Most of ICP consider end to end IPv4 together with outside in and inside
out;

3) Load balance is still needed which is same as today IPv4 even there are
no more traffic for IPv6,
for most ICP, they need to know the geo-location information during the
packet going through the load balance.

4) ICP need to fully understand how to avoid DDOS when they launch the
IPv6, otherwise they will always need NAT solution

Regards,

-Hui

2012/2/23 Brian E Carpenter <[email-masked]>

> Internet-Draft directories: http://www.ietf.org/shadow.html

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Mar 2012 08:14:58 +1300

Hi Deng,

> be based on their own location, which may have different consideration;

I think that our main target is an ICP that is mainly familiar with IPv4.
In the case of an ICP hosted by a hosting provider or IDC, I suppose we
are addressing the hosting provider, and we should say that.

> 2) Most of ICP consider end to end IPv4 together with outside in and inside

Yes, we are assuming they are already supporting e2e IPv4.

> no more traffic for IPv6,

Not if only 1% of the traffics is from IPv6. It's only when the traffic
becomes large that you need load balancing.

> packet going through the load balance.

Sure. The point is only that the quality of the geolocation lookup
is alleged to be weaker for IPv6 today. Obviously this will improve.

> IPv6, otherwise they will always need NAT solution

Can you explain that please?

Thanks

    Brian

---

From: Arturo Servin <[email-masked]>
Date: Sun, 11 Mar 2012 13:23:28 -0600

Brian,

Even 1% may need load balancing for high availability. IMHO.

Regards,
as

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 11 Mar 2012 12:23:36 -0700

> IPv6, otherwise they will always need NAT solution

I'm mystified by this statement... network address translators that
aren't stateless  (much like firewalls) are a huge DOS bottleneck in a
service that accepts unsolicited incoming connections. As far as I'm
concerned they shouldn't be employeed unless they can be load-balanced.

If they cause the loss of the original v6 source address along the way
that's no good since I need that.

> Regards,
>  
> -Hui
> 
> 
> 2012/2/23 Brian E Carpenter <[email-masked]
> <mailto:[email-masked]>>
> 
>     Hi,
> 
>     From: [email-masked] <mailto:[email-masked]>
>     Reply-To: [email-masked] <mailto:[email-masked]>
>     To: [email-masked] <mailto:[email-masked]>
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     Internet-Draft
>     <https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>
>     directories: http://www.ietf.org/shadow.html
>     [email-masked] <mailto:[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Mar 2012 08:39:45 +1300

> Even 1% may need load balancing for high availability. IMHO.

At least you need server redundancy, yes, good point.

  Brian

---

From: Hui Deng <[email-masked]>
Date: Mon, 12 Mar 2012 12:00:32 +0800

inline please,

2012/3/12 Brian E Carpenter <[email-masked]>

> becomes large that you need load balancing.
loading balancing is sitting together with DDOS prevention and many other
features, even 1%, they still need it.

> is alleged to be weaker for IPv6 today. Obviously this will improve.
this information is bundled with many other ICP services, this have to be
considered anyway by them.

> Can you explain that please?
this expecting that this document could explain how to avoid DDOS in
detail, otherwise, they have to deploy special NAT to handle this by
configure some policy over there.

-Hui

---

From: Hui Deng <[email-masked]>
Date: Mon, 12 Mar 2012 12:02:51 +0800

2012/3/12 Joel jaeggli <[email-masked]>

> that's no good since I need that.
you are right, NAT is stateful as well, but by configuring some policy on
the NAT, then
such kind of DOS could be avoided, which save those servers sitting behind.

-Hui

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Mar 2012 09:14:26 +1300

Hi,

On 2012-03-12 17:00, Hui Deng wrote:
...
> configure some policy over there.

I am very confused about how a NAT algorithm can be configured to detect
a DDOS attack. I can certainly understand that a box that contains a NAT
algorithm might also contain a DDOS detection algorithm, but that is
a separate question.

Maybe what we need is a specific document on detecting and defeating DDOS
attacks in IPv6? That sounds like a major topic in itself, and it isn't
only for ICPs.

   Brian

---

From: Hui Deng <[email-masked]>
Date: Tue, 13 Mar 2012 12:22:59 +0800

Hi Brian

I am fine to keep it a seperate topic, maybe write an guidance document for
Prevention from DDOS in IPv6 sounds reasonable

-Hui

2012/3/13 Brian E Carpenter <[email-masked]>