Subject: Enterprise Analysis DSTM Issue

From: "Bound, Jim" <[email-masked]>
Date: Tue, 9 Aug 2005 16:02:20 -0400

WG Members,

For DSTM we are going to discuss as authors what we want to do here per
Fred's mail telling us we could go away if we leave it in the spec, at
least my read of his mail. This will take us a few weeks as some are on
summer vacation.

For your information if your new.  DSTM had a minimum of two years IETF
NGTRANS working group discussion, and had discussion before that as the
AIIH proposal.  In fact the authors reduced and altered the DSTM
protocol several times per the NGTRANS Chairs input over the years and
the WG.  

There will be a series of DSTM specifications sent for Experimental RFC
in the next 6 months.  At the same time there will be a new industry
focus on DSTM, that will be quite rigorous, and produce a set of
deployment guidelines including DSTM for the IPv6 Transition.  

I realize DSTM is not an Experimental RFC now, but that was because we
were not sure best path to move the work until about 3 weeks ago.  But
ISATAP is still awaiting Experimental RFC, was only discussed in NGTRANS
too, not v6ops, and we still need a Tunnel Set Up Protocol.  Yet both of
these are fine to reference in the spec?  If true, is that "fair".

DSTM is a mechanism that is part of the plan for several enterprises, it
is a valid reference.

No need to respond or support this mail that is not its purpose.  But I
want you the WG members to understand our decision or my "individual"
decision when it is made in the next few weeks.

Also it would have been nice if this could have been brought up when I
asked are there other issues in person at the Paris IETF last week.  We
could have all met that care in person then at that IETF event.

/jim

---

From: Fred Baker <[email-masked]>
Date: Tue, 9 Aug 2005 13:50:18 -0700

let's clarify on the conversation.

a) Pekka said that the term "Dual-Stck" was heavily overloaded, and  
it didn't seem wise for the working group to recommend something that  
was so unclear.

b) You said that you had no intention of removing DSTM (your  
experimental work) from the draft regardless of working group  
(Pekka's) input, because you had customers interested in running DSTM.

c) I said that a working group draft needs to reflect working group  
input, and that if this could not be accomplished then maybe the  
document should not be a working group document.  That is not a  
position I plan to apologize for; it is also related to the reason  
that v6ops doesn't work on transition strategies - the various  
transition discussions in v6ops did not lead to convergence on a  
single or small number of recommended strategies.

d) You now have your back up.

Pekka's comments originate from the dual use of the term "dual  
stack". The IETF has a long-standing recommendation that a network  
should run both IPv4 and IPv6 (network layer forwarding, routing, and  
so on) natively, allowing end systems to use either protocol with the  
expectations one would have of any native deployment. This is  
described as "dual stack" in RFC 1933 and its successor 2893, in  
several RFCs describing potential transition mechanisms (2765, 2766,  
and 2767 come quickly to mind). The term "dual stack" is also used by  
DSTM. But DSTM doesn't actually run two stacks in the network. It  
runs an IPv6-only network (at least as far as its customers are  
concerned) and provides a way for IPv4 systems to rendezvous over it  
and tunnel through it, allowing end systems to run dual stacks. In  
your words:

      DSTM [DSTM, DSTM+] is a useful tunneling mechanism for later in  
the
      enterprise transition or deployment of IPv6-dominant network links
      is desired. DSTM is to being submitted as an IETF Experimental  
RFC.

Pekka's observation is that while this is mostly transparent to the  
end system, it is hardly transparent in the network and (being  
experimental) is not something the IETF is at this time recommending.  
This reflects my comment to you of perhaps two months ago. I'm all  
for your draft discussing dual stack mechanisms - mechanisms that use  
two stacks, consistent with RFC 2893. But recommending DSTM in a  
working group recommendation is not consistent with its experimental  
status. RFC 2026 says, in section 4.2.1:

    The "Experimental" designation typically denotes a specification  
that
    is part of some research or development effort.  Such a  
specification
    is published for the general information of the Internet technical
    community and as an archival record of the work, subject only to
    editorial considerations and to verification that there has been
    adequate coordination with the standards process (see below).  An
    Experimental specification may be the output of an organized  
Internet
    research effort (e.g., a Research Group of the IRTF), an IETF  
Working
    Group, or it may be an individual contribution.

and in section 3.3:

    (d)  Limited Use:  The TS is considered to be appropriate for use
         only in limited or unique circumstances.  For example, the  
usage
         of a protocol with the "Experimental" designation should  
generally
         be limited to those actively involved with the experiment.

In other words, an experimental protocol or procedure may be a  
perfectly good protocol or procedure and may be a candidate for  
future standardization. It may have customers using it. However, its  
general utility has not been shown at the point in time that it has  
been given that status, and the protocol or procedure is not  
recommended for general deployment until the experiment has been run.

So, I have two expectations of a working group document: that it  
reflect the opinions of the working group, and that it reflect the  
recommendations of the IETF. As you and I discussed in July, the  
statement

      Later in the transition process, after the enterprise has
      transitioned to a predominately IPv6 infrastructure, the architect
      should implement the Dual-IP Transition Mechanism [DSTM, DSTM+].

fails the latter point, and from the sound of Pekka's comment, fails  
the former point as well.

I appreciate that you are accepting a number of Pekka's other  
comments. I'd like you to consider carefully his comment regarding DSTM.

---

From: Tim Chown <[email-masked]>
Date: Tue, 9 Aug 2005 22:13:55 +0100

> single or small number of recommended strategies.

And here's the funny thing, or it is if I understood Paris correctly.  
At IETF 62, the v6tc BoF showed one way forward for nailing down tunnelling
solutions (which could include DSTM).  Sadly due to blockage somewhere in 
the IETF upper reaches the WG never formed.  At Paris, a non-advertised BoF
on tunneling, called 'lrw' (!?) was held with near-identical goals to v6tc.
And now we hear that lrw (hopefully with a better name) will be formed, and
as an Internet area WG will be able to do protocol work.   Provided the
work is based on existing drafts.  This is good.

So after all the stalling since ngtrans closed up, we now have a WG that
*could* publish DSTM, or something very like it, potentially, since it covers
4 in 6 and 6 in 4 in its charter (and oddly inter-network tunnelling).

Anyway, one could see tunneling protocols emerging soon from lrw.

> experimental) is not something the IETF is at this time recommending.  

But lrw has something not too different as its goal?

<devil's advocate>
What does the IETF recommend for dual-stack nodes in an IPv6 infrastructure?
</devil's advocate>

> the former point as well.

Something 'like it' is likely to be needed though?   e.g.

      transitioned to a predominately IPv6 infrastructure, the architect
      is likely to need to deploy IPv4-in-IPv6 tunnelling solutions, such
      as the Dual-IP Transition Mechanism [DSTM, DSTM+].
?

But again, what would the IETF's recommended tool be here?

Tim

---

From: Fred Baker <[email-masked]>
Date: Tue, 9 Aug 2005 14:55:55 -0700

> What does the IETF recommend for dual-stack nodes in an IPv6  

The IETF's current recommendations are encapsulated in http:// 
www.ietf.org/rfc/rfc2893.txt. The abstract is:

    This document specifies IPv4 compatibility mechanisms that can be
    implemented by IPv6 hosts and routers.  These mechanisms include
    providing complete implementations of both versions of the Internet
    Protocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4
    routing infrastructures.  They are designed to allow IPv6 nodes to
    maintain complete compatibility with IPv4, which should greatly
    simplify the deployment of IPv6 in the Internet, and facilitate the
    eventual transition of the entire Internet to IPv6.  This document
    obsoletes RFC 1933.

As Jim is wont to point out, this doesn't address the case of an IPv6- 
only infrastructure. The deployment of IPv6-only infrastructures  
greatly complicates the transition, as we have no guarantee that  
there is a way to bridge IPv6 deployed over any given IPv4  
infrastructure, and the presence of IPv6-only infrastructures means  
that we can no longer make that guarantee for IPv4/IPv6 either. In  
addition, given that there are a variety of different transition  
models, many of which similarly pick off a piece of the puzzle  
without analyzing its effectiveness end to end:

         draft-blanchet-v6ops-tunnelbroker-tsp-02.txt
         draft-despres-v6ops-transition-v5roadmap-00.txt
         draft-huitema-v6ops-teredo-05.txt
         draft-kim-v6ops-ipv6overwibro-issues-00.txt
         draft-liumin-v6ops-silkroad-03.txt
         draft-massar-v6ops-heartbeat-01.txt
         draft-massar-v6ops-tunneldiscovery-00.txt
         draft-ooms-v6ops-bgp-tunnel-05.txt

Even if every IPv4-only or IPv6-only network provides a way to bridge  
the other over it, I'm not aware of a proof that end-to-end  
connectivity is eventually assured, as I don't have a guarantee that  
they will not touch each other and (as would be required) provide all  
relevant transition mechanisms over all relevant paths. There is a  
good article on this concept at http://www.isen.com/papers/ 
Dawnstupid.html. Yes, you heard this from someone whose day job is  
with a company that likes to talk about the "Intelligent Information  
Network". Let's just say that I don't work in marketing...

Oh, by the way, as IPv4 address space allocation in fact approaches  
impossibility, the deployment of IPv6-only infrastructure is not only  
predictable, it is unavoidable. At this point, it is very avoidable,  
and I have a hard time arguing that the complications resulting from  
it are preferable to the complications of running a dual stack network.

I'm all for lrw, v6tc, or whatever it winds up being called. I was  
last time around as well. AFAIK, v6tc is *also* not chartered to  
solve the entire complexity of the end to end problem - it is  
chartered to come up with a rendezvous protocol for a tunneling  
solution, and presumably not a dozen mutually incompatible ones. From  
what Mark Townsley and Dave Ward told me, something like DSTM might  
be part of that, but it has to manage an arbitrary underlying tunnel  
architecture - MPLS, ATM, L2TP, IP/IP6, GRE6, etc, and perhaps a  
couple of such strung together end to end - and is therefore probably  
not exactly DSTM. But DSTM would be a useful input. I don't think we  
should be deploying IPv6-only networks in any form until we have  
figured out the end to end problem.

---

From: Tim Chown <[email-masked]>
Date: Wed, 10 Aug 2005 14:12:43 +0100

> it are preferable to the complications of running a dual stack network.

I think for the majority of cases/networks that's true.  But I have spoken
to people recently who believe (conventional) dual-stack adds to security
complexity, and they'd like to run one protocol only.  

RFC4057 (section 3.1) defines the IPv6-only infrastructure scenario as
one of the three base secenarios:

   Scenario 3:   IPv6-only network infrastructure with some IPv4-capable
                 nodes/applications needing to communicate over the IPv6
                 infrastructure.  Enterprise deploying a new network or
                 restructuring an existing network, decides IPv6 is the
                 basis for most network communication.  Some IPv4
                 capable nodes/applications will need to communicate
                 over that infrastructure.

so it seems to be appropriate to cover the potential solutions in the
analysis document.   I know Pekka was reluctant to include that scenario
while he was co-chair, but consensus was there and it was included.
 
My view is that something 'DSTM-like' will be needed for Scenario 3, but
(for whatever reason) we have nothing on standards track that solves that
case yet.   The analysis wording should describe the nature of the solution,
and could cite DSTM as one example.    

> solution, and presumably not a dozen mutually incompatible ones. 

Agreed, it was supposed to find one solution.

> From what Mark Townsley and Dave Ward told me, something like DSTM might  
> not exactly DSTM. But DSTM would be a useful input. 

I agree.

> I don't think we should be deploying IPv6-only networks in any form until 
> we have figured out the end to end problem.

If there are overall connectivity concerns with the model, these should be 
discussed of course.  Maybe a short text/draft describing the problem would 
be useful input? :)  Brief text and a couple of example concerns?

-- 
Tim/::1

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 11 Aug 2005 11:07:16 +0200

(this is somewhat off-topic I guess)

> complexity, and they'd like to run one protocol only.

I must miss something here. In what way would these people think the  
security model differed from any other tunnelling model for security?  
I.e the payload is the payload is the payload, and from my experience  
that is what is hard to secure...the only way to protect them then is  
to either leave out the v4 Internet (which might not be a bad idea  
from security POV :-) or do translation?

- kurtis -

---

From: Tim Chown <[email-masked]>
Date: Thu, 11 Aug 2005 11:51:44 +0100

> from security POV :-) or do translation?

Sorry if I was not being as clear as I could be.

There's some overlap betweeen DSTM and conventional dual stack in this 
discussion.  I'm saying that some (UK) people have mentioned to me that they
do not want to run dual-stack because they believe it adds complexity to 
security, and thus would want to run IPv6 only, or at least IPv6-only network 
infrastructure.  Given the latter, if they have some dual-stack hosts,
something DSTM-like in functionality may be required.  They are also 
evaluating NAT-PT, etc in light of this.

The concern expressed was the fact that two protocols are in use, and both
need to be secured, mainly with consistent policies and with some IPv6
specific policies.

I'm not saying I agree with that assessment (which is why we run conventional
dual-stack on our 1,000+ node network here) but the requirement seems to be
there.  Maybe it's an education issue like NAP.

Of course, the DSTM-like protocol and NAT-PT have their own security 
implications...

-- 
Tim/::1

---

From: Pekka Savola <[email-masked]>
Date: Thu, 11 Aug 2005 14:05:13 +0300 (EEST)

> need to be secured, mainly with consistent policies and with some IPv6

So, if I get this correctly, the fear is about attacks on the 
network infrastructure (routers, etc.), not on the end hosts ?

Because as long as you WILL have v6 connectivity through [v4-in-v6 
tunneling] on the end hosts, you will STILL have the same security 
problems?  You've just shifted them around to a different place in the 
topology.

But if the assumption is that an enterprise/university could run 
entirely v6-only core (routers, switches, what have you, without 
[v4-in-v6 tunneling] for their management or whatever), yes, there 
might be small differences.

My assumption has always been that the network admins should be 
capable of secuiring the routers, switches, etc. properly (in any 
case, the same degree they could do so with v6), but maybe my optimism 
isn't shared everywhere..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Tim Chown <[email-masked]>
Date: Thu, 11 Aug 2005 12:10:18 +0100

> network infrastructure (routers, etc.), not on the end hosts ?

Yes, I think so.
 
> isn't shared everywhere..

Seems so.

As I said, I'm just relaying comments that I have heard.

-- 
Tim/::1