Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00

["Templin, Fred L" <[e-mail]>]

Hi Fred, 

> -----Original Message-----
> From: Fred Baker [mailto:[e-mail]] 
> Sent: Monday, February 07, 2011 11:12 AM
> To: Templin, Fred L
> Cc: IPv6 Operations
> Subject: Re: [v6ops] Fwd: New Version Notificationfor 
> draft-troan-v6ops-6to4-to-historic-00
> 
> 
> On Feb 7, 2011, at 10:04 AM, Templin, Fred L wrote:
> > Why not something better? Why not IRON:
> 
> "Better" is a value judgement, a comparison of a proposed 
> solution with a set of requirements, and is often somewhat in 
> the eye of the beholder.

My (partial) set of requirements that IRON satisfies includes:

1) IPv6 rollout - must support fast incremental deployment
   of IPv6 as IPv4 address depletion escalates

2) NAT traversal - must work through NATs w/o being unduly
   dependent on NAT state stability  

3) Routing Scaling - scaling to large numbers of end systems
   and networks using IPv6 must not adversely impact routing
   scaling in the core

4) Mobility management - must maintain generally shortest path
   routing for mobile end systems and networks without producing
   undue routing churn in the core

5) Multihoming - must support simultaneous connections through
   multiple providers

6) Traffic engineering - must allow customer to dynamically
   manage both in-bound and out-bound traffic classification,
   i.e., even if the link paths are asymmetric in the forward
   and reverse directions. (For example, send packets out via
   a 3G link and receive packets back via a DOCSIS link.) 

7) Provider (In)dependence - end systems and networks should
   be able to use a single, stable IPv6 address or prefix via
   multiple provider connections.

> I think it would be fair to say that the objective of v6ops 
> is to deploy, operate, and maintain a ubiquitous IPv6 network 
> comparable to the IPv4 network of today and independent of 
> any underlying infrastructure. There may well be underlying 
> infrastructure of various kinds - ATM, MPLS, various WAN 
> technologies, or "Ethernet" in whatever form it may appear at 
> the moment. However, the networks that the operators on this 
> list operate are not networks in which one expects hosts to 
> dynamically place circuits on an infrastructure of a 
> different kind to provide service, but to operate as a 
> ubiquitous and stable service. 
> 
> It may be fair to ask each type of technology to describe its 
> relationship to that kind of service, and to carefully 
> consider the operational implications of running it. That's 
> where Ole is coming from in suggesting that RFC 3056 be 
> retired; it depends on an underlying infrastructure (IPv4 
> addressing and anycast servers), and has been a source of 
> problems for ISPs trying to deploy native IPv6 service as 
> noted in RFCs 3964 and 4472, and in the drafts 
> draft-ietf-v6ops-tunnel-loops, 
> draft-ietf-v6ops-tunnel-security-concerns, 
> draft-kuarsingh-v6ops-6to4-provider-managed-tunnel, and 
> draft-vandevelde-v6ops-harmful-tunnels. That is also at least 
> in part where questions of other overlay networks like Teredo come in.

The class of services you are referring to above have in
common that they embed an IPv4 address within the IPv6
address and later extract such IPv4 addresses for stateless
tunnel endpoint discovery. IRON does not share this property.
 
> If I can summarize Keith's concern with 6rd, it is not that 
> it doesn't deploy an IPv6-capable service; it is that the 
> service has a smaller Path MTU than the native MTU of links 
> he uses, often has a broken PMTU implementation due to ICMPv6 
> filtering, and is not native. If I can summarize the views of 
> those using it (such as a Dutch provider I spoke with 
> Wednesday in London), it's not that they don't want or expect 
> to deploy a native IPv6 service, it's that they want to 
> deploy an IPv6 service now and have infrastructure that they 
> can't immediately upgrade (such as, in the Dutch case I 
> mentioned, a service network that they have to use that is 
> IPv4-only for the foreseeable future).
> 
> Similar exchanges can be described around dIVI, 4rd, and 
> ds-lite. Fundamentally, if my bread and butter today is IPv4 
> and my shiny new IPv6 network will in the nature of the case 
> require some time to harden, why would I disrupt my bread and 
> butter to deploy the new, and while doing so make my present 
> business model dependent on the not-yet-hardened network? 
> They are very reasonable ways to remove IPv4 from a dual 
> stack network, but from the perspective of risk an odd way to 
> deploy the IPv6 network.
> 
> If you want to make the case that IRON is "better" than 
> something else, I think the thing to do is write the 
> applicability statement.

We already have one of these in the RFC editor queue:

http://www.rfc-editor.org/internet-drafts/draft-russert-rangers-05.txt

Section 6 of that document in particular provides a problem
statement for which IRON is the proposed solution.

> The networks on this list operate as 
> a ubiquitous and stable service comparable to the present 
> IPv4 network and independent of any underlying 
> infrastructure; anything else needs to help them move toward 
> that goal, and needs by nature to be effortlessly removed 
> from the network as native IPv6 deployment settles in. What 
> is the applicability of IRON to such a network?

I don't agree with the "needs to be effortlessly removed"
comment - even if and when a native IPv6 deployment settles
in - since IRON runs just fine over either IPv4 or IPv6
networks. Although IRON does offer a fast-path incremental
deployment of a tunneled IPv6 service for the near term,
that service will still be attractive to customers for the
long term due to its support for mobility, multihoming,
traffic engineering and provider (in)dependence.

The reason I write it as "provider (in)dependence" is that
IRON requires someone to stand up an affordable service; see:

http://tools.ietf.org/html/draft-templin-iron-pm

To prospective IRON network operators, what is required
is strategic deployment of a few IRON relays (maybe O(10)
of these) and a number of IRON servers (maybe O(100) to
O(1000) of these). The IRON relays are full-fledged routers
that run eBGP externally and iBGP internally. The IRON
servers are low-cost commodity devices that can be purchased
at your local computer wholesaler. Performance can therefore
be tuned by ensuring that the IRON relays are well-deployed
(much in the same way as for responsibly-deployed 6rd/6to4
relays) and/or by adding additional low-cost servers in
regions where server load may become substantial.

Again, IRON is about fast transition today with a service
customers will find attractive continuing into the long
term - a once-and-done alternative.

Thanks - Fred
[e-mail]