Subject: [v6ops] draft-anderson-v6ops-siit-dc-01

From: Ca By <[email-masked]>
Date: Sun, 7 Dec 2014 22:35:26 -0800

I have read  draft-anderson-v6ops-siit-dc-01.

I support the document to be republished as a WG informational document
with  the RFC6145 changes  moved into a new document.

I have a one minor comments about draft-anderson-v6ops-siit-dc-01.

The I-D identifies a real network scaling problem where dual-stack is not
an acceptable solution since it does not allow network operators to
decouple IPv4 addresses from nodes deployed, thus nodes deployed cannot
scale beyond IPv4 address holdings with dual-stack.  The IETF needs to
provide better guidance than  "dual-stack everything".  But, the I-D does
not address the simplest solution of simply having IPv4 nodes for IPv4
traffic and IPv6 nodes for IPv6 traffic.  This allows a data center
operator to get the most usage out of scarce IPv4 nodes since they pick up
the IPv4-only users (excluding Apple happy eyeballs!!!) while the IPv6
nodes pickup the IPv6 capable users.  Now, this approach of IPv4-only nodes
and IPv6-only nodes works great when you are Facebook and your smallest
unit of provisioning is a fully packed rack of gear.  If you are a smaller
operator, you may not have enough traffic to justify an IPv6-only node, yet
you still have to scale nodes beyond IPv4 holdings.  There is also the case
where uniformity of provisioning is seen as being a higher value than
having 2 flavor: v4 and v6... thus draft-anderson-v6ops-siit-dc-01
certainly fits a need, but it should be context of dual-stack and single
stack v4 and v6.

---

From: Tore Anderson <[email-masked]>
Date: Mon, 8 Dec 2014 09:42:53 +0100

* Ca By <[email-masked]>

> with  the RFC6145 changes  moved into a new document.

Thank you!

> certainly fits a need, but it should be context of dual-stack and single

I'm not so sure about having separate IPv4-only and IPv6-only
infrastructures solves anything, actually...

To continue the Facebook analogy with a rack of IPv4-only frontend
nodes and another rack of IPv6-only frontend nodes that serve IPv4-only
and IPv6-capable users: Presumably all those users need to be shown the
same content, regardless of which IP version they used to request it.
So those IPv4/IPv6-only frontend racks necessarily share a common set
of backend servers - and if they're to be reachable from both the
IPv4-only and the IPv6-only frontend nodes, then the backend nodes must
necessarily be dual-stack.

So we're back to IPv4 being a limiting factor for scaling, and in my
experience the number of backend nodes usually greatly outnumber the
number of frontend nodes so really this is where you primarily would
want to avoid dual-stack. (If we're talking about Facebook or someone
of similar size, dual-stack using RFC1918 for IPv4 in the backend
doesn't necessarily scale well enough either.)

Tore

---

From: Ca By <[email-masked]>
Date: Mon, 8 Dec 2014 07:33:19 -0800

On Monday, December 8, 2014, Tore Anderson <[email-masked]> wrote:

> * Ca By <[email-masked] <javascript:;>>
>
Let's assume the backend is ipv6-only.

The ipv4-only front-end is in-fact dual stack but it has public v4 in
public dns to be reached by clients but no public dns entry on the ipv6
side.  This is what allows for the separation of ipv4 and v6 users

---

From: Tore Anderson <[email-masked]>
Date: Tue, 9 Dec 2014 10:37:06 +0100

> > > The I-D identifies a real network scaling problem where
> > > dual-stack is not an acceptable solution since it does not allow
> > > network operators to decouple IPv4 addresses from nodes deployed,
> > > thus nodes deployed cannot scale beyond IPv4 address holdings
> > > with dual-stack.  The IETF needs to provide better guidance than
> > > "dual-stack everything".  But, the I-D does not address the
> > > simplest solution of simply having IPv4 nodes for IPv4 traffic
> > > and IPv6 nodes for IPv6 traffic.  This allows a data center
> > > operator to get the most usage out of scarce IPv4 nodes since
> > > they pick up the IPv4-only users (excluding Apple happy
> > > eyeballs!!!) while the IPv6 nodes pickup the IPv6 capable users.
> > > Now, this approach of IPv4-only nodes and IPv6-only nodes works
> > > great when you are Facebook and your smallest unit of
> > > provisioning is a fully packed rack of gear.  If you are a
> > > smaller operator, you may not have enough traffic to justify an
> > > IPv6-only node, yet you still have to scale nodes beyond IPv4
> > > holdings.  There is also the case where uniformity of
> > > provisioning is seen as being a higher value than having 2
> > > flavor: v4 and v6... thus draft-anderson-v6ops-siit-dc-01
> > > certainly fits a need, but it should be context of dual-stack and
> > > single stack v4 and v6.
> >
> > nodes and another rack of IPv6-only frontend nodes that serve
> > IPv4-only and IPv6-capable users: Presumably all those users need
> > to be shown the same content, regardless of which IP version they
> > used to request it. So those IPv4/IPv6-only frontend racks
> > necessarily share a common set of backend servers - and if they're
> > to be reachable from both the IPv4-only and the IPv6-only frontend
> > nodes, then the backend nodes must necessarily be dual-stack.
> >
> >
> public dns to be reached by clients but no public dns entry on the
> ipv6 side.  This is what allows for the separation of ipv4 and v6
> users

I see. I think I'd call this «Partial dual-stack» or somthing like it.
I don't think there is a material difference between having a single
set of dual-stacked frontends, or two separate sets of frontends (one
IPv6-only serving IPv6 users and the other dual-stack serving IPv4
users). The properties of such a solution remains the same, essentially:

The Good:

* No translation, so end-to-end principle remains intact..
* Compatible with all application protocols
* Alleviates IPv4 address scarcity to almost the same extent as SIIT-DC
  but not quite (as IPv4 addresses are still required for non-service
  purposes like the DC network infrastrucuture and some might go to
  wast due to subnets being rounded up to the next CIDR boundary).

The Bad:

* You still dual-stack in places, resulting in increased complexity.
  Apart from the frontend servers themselves and the applications
  running on them, this also applies to the DC network infrastructure,
  including any firewalls, ACLs, load balancers, etc.
* Can't support any IPv4-only application software, application
  protocols, or devices in the backend.

I'm thinking I could write up a separate appendix B.5 to describe this.

Tore

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 9 Dec 2014 15:27:00 +0000

On Dec 9, 2014, at 1:37 AM, Tore Anderson <[email-masked]> wrote:

> I think I'd call this «Partial dual-stack» or somthing like it.

I suspect you’re both right, but in different ways. The particular machine(s) are dual stack (they have two stacks), but they have only IPv6 addresses on at least one interface (they might also have only IPv4 addresses on another interface, but that’s not a requirement). As a result, a message passing through is IPv4 on one side and IPv6 on another. But nothing else has to be dual stack. So the *network* is only partially dual stacked.