Subject: RE: DSTM-ports Considered Harmful [Re: (ngtrans) final ngtransagendaforIETF-53 in Minneapolis]

From: "Bound, Jim" <[email-masked]>
Date: Tue, 19 Mar 2002 02:16:50 -0500

thats good logic and I can't refute it.  and we cannot change the DSTM
assumptions that would be unacceptable.  The assumption is really a
deployment strategy and thats the whole point of DSTM.  So if we cannot
make any DSTM option support that assumption in my view the option is
DEAD.  

but why not at least discuss the other benefit which is this.

with the port option is it possible to give the user back e2e with its
limited IPv4 address space.  Kind of like right-sizing a bad situation
and helping the user along.
Just in case they cannot move to a pure Native IPv6 network till say
2005.

See thats my urgency.  IPv6 is being deployed now and they are thinking
reduce the use of IPv4 as a strategy in the market as a usual consistent
message to vendors.  Thats why we made sure Web, Mail, Messaging, BIND,
and some others can work over native IPv6.  This permits the immediate
use if IPv6 native shows up but also if it does not.  But if it does not
then DSTM helps out.  And DSTM port options helps out the poor user with
very limited address space on their Intranet or in their Home.

Also I don't know of any initial handhel products that support an IPv6
ONLY stack.  They all support a dual stack so it works for them too.

But we have to believe the port option is worth the work.  One advantage
that RSIP did not have is that IPv6 transition mechanisms are being
built now.  So clients and servers can support it as add on.  Pretty
tough business case to change IPv4 existing software for RSIP.  I do
like RSIP for IPv4 too as a note and think it is good idea but I would
rather see IPv6 than proliferation of NAT with IPv4.

/jim

/jim

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Tuesday, March 19, 2002 12:04 AM
> To: Myung-Ki Shin
> Cc: Francis Dupont; Alain Durand; Yasevich, Vladislav; NGtrans List
> Subject: Re: DSTM-ports Considered Harmful [Re: (ngtrans) final
> ngtransagendaforIETF-53 in Minneapolis]
> 
> 
> On Tue, 19 Mar 2002, Myung-Ki Shin wrote:
> > Pekka Savola wrote:
> > 
> > > I'm not sure if that's a goal of DSTM: the goal of DSTM 
> is to be able to
> > > run IPv6-only network infrastructure with dual-stack nodes.
> > >
> > > Sure, getting end-2-end IPv4 is always a plus, but 
> nothing specific to
> > > DSTM. And there should be some use for IPv6 too ;-)
> > 
> >    No, see the section 3. DSTM Overview and Assumptions in 
> DSTM spec.
> >    
> http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-07.txt
> > 
> >    ====
> >    The core assumption within this mechanism is that it is totally
> >    transparent to applications, which can continue to work with IPv4
> >    addresses. It is also transparent to the network, where only IPv6
> >    packets are carried. It is the authors' viewpoint that 
> the user, in
> >    this case, has deployed IPv6 to support end to end 
> computing without
> >    translation.  This aspect is fundamental during a 
> transition process
> >    to guarantee that every existing application will 
> continue to work
> >    (e.g. IPsec, H.323), despite the presence of IPv4 
> addresses in the
> >    payload of a packet.
> 
> Ah, missed the last part.
> 
> But DSTM ports still does not seem to fulfill that requirement:  some
> applications *will* cease to work (or more precisely, 
> probably start to
> disrupt the applications of other DSTM nodes).. and then 
> _every existing 
> application_ will most definitely not work.
> 
> When we break the assumption we have a couple of choices:
> 
>  1) revise the assumptions (DSTM draft)
>  2) acknowledge that both will break the assumption, but continue 
> regardless
>   a) by specifying more (dstm-ports)
>   b) by letting the user continue as he did before 
> implementing DSTM (do 
> nothing)
> 
> IMO, 2.b) is obvious: if the site had enough IPv4 addresses 
> to guarantee 
> end2end before DSTM, in most cases it has enough IPv4 addresses after 
> DSTM too.  On the other hand, if the site didn't have enough IPv4 
> addresses, e2e applications were broken _to begin with_, and 
> DSTM causes 
> no _additional_ problems.
> 
> -- 
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
> 
>

---

From: Stig Venaas <[email-masked]>
Date: Tue, 19 Mar 2002 16:35:33 +0100

> Just in case they cannot move to a pure Native IPv6 network till say

I agree the port option is a bit ugly, but it's much much better than
NAT which would be the alternative. If someone has enough IPv4 addresses
they shouldn't use this option. If you have very few IPv4 addresses, you
may be forced to share an address between multiple hosts. Doing this the
DSTM+port/RSIP way breaks very few applications compared to NAT(-PT).
In particular addresses and ports embedded in the application protocol
is less of a problem. I think much of what is said about RSIP in RFC
3103 also applies to DSTP+port.

Stig

---

From: Octavio Medina <[email-masked]>
Date: Tue, 19 Mar 2002 17:12:27 +0100

I totally agree. Adding NAT to DSTM is a bad idea. Adding NAT no
anything is a bad idea anyway. I think the other authors of DSTM agree
with me that one of the main goals of DSTM is to AVOID translation. I
will never support adding a NAT to DSTM to solve the
lack-of-IPv4-addresses problem. I believe DSTM ports is a better choice
for that.

-Octavio

---

From: Pekka Savola <[email-masked]>
Date: Tue, 19 Mar 2002 18:19:36 +0200 (EET)

On Tue, 19 Mar 2002, Octavio Medina wrote:
> lack-of-IPv4-addresses problem. 

But the site which does this had a problem with lack of IPv4 addresses to 
being with!

I've yet to hear of an organization (except for a very few examples) which
would have to give back IPv4 addresses if it starts using IPv6!

> I believe DSTM ports is a better choice
> for that.

Sure, it _sounds_ an interesting idea.

But I don't think it's going to _work_ in a robust, reliable way except 
under some very specific scenarios.

Therefore I think ports option can be very bad: I wouldn' want to define 
even an optional _IPv6_ mechanism that may be unreliable, etc.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 19 Mar 2002 17:30:06 +0100

> would have to give back IPv4 addresses if it starts using IPv6!

If you are forced to use NAT (pure IPv4) because of lack of IPv4 addresses
today, you can improve the situation by moving to DSTM ports or RSIP.

> even an optional _IPv6_ mechanism that may be unreliable, etc.

I understand your concern, but I think it might be possible to implement
this reliably, at least for applications that use ephemeral ports. The
main problem I see is that if you have a shared port space for IPv4 and
IPv6, you must make sure the port space used for IPv6 ephemeral ports
are separate from the ports you might be given from the DSTM server. Do
you see other problems? Could be useful to check if there are any RSIP
implementations and how good they work, I think they are facing exactly
the same issues.

Stig

---

From: Pekka Savola <[email-masked]>
Date: Tue, 19 Mar 2002 18:39:09 +0200 (EET)

> implementations and how good they work, I think they are facing exactly

One way to restrict the others from misbehaving nodes would be to install 
a firewall policy in TEP which discards packets with invalid port ranges.

I don't think it's easy to say much about the practical usability of DSTM
ports until it's implemented and tested; perhaps an experimental RFC might
be ok, but I really think this may be opening too big a can of worms for
us to handle.

---

From: Octavio Medina <[email-masked]>
Date: Tue, 19 Mar 2002 17:54:57 +0100

> would have to give back IPv4 addresses if it starts using IPv6!

You cannot focus in today's situation. You have to consider that the
number of computers you have will continue to grow and there will be a
day where you will no longer be able to ask for more v4 space. That will
be a problem, if want to maintain e2e connectivity.

> even an optional _IPv6_ mechanism that may be unreliable, etc.

Of course more work needs to be done in order to show how "very
specific" the scenarios for DSTM ports really are. Remember that DSTM is
to be used ONLY when no other means of communication is possible. We
have done some studies that show that most IPv4 sessions in our domain
are http. In that case, you don't even need DSTM. Putting an ALG (an
IPv4/IPv6 web proxy) is enough. This considerably reduces the need of
IPv4 addresses, reducing the size of the address pool. DSTM ports is to
be used only in extreme cases, when even the use of ALGs and the Dynamic
temporary address allocation in standard DSTM can not satisfy th demand
of IPv4 addresses.
 
-Octavio

---

From: Stig Venaas <[email-masked]>
Date: Tue, 19 Mar 2002 17:51:39 +0100

> a firewall policy in TEP which discards packets with invalid port ranges.

The effect would be similar to stealing someones IPv4 address. In general
the TEP should discard packets with invalid IPv4 source addresses (by
checking that the IPv4 address was given to the host with the IPv6 source
address used). Using ports it seems reasonable to also filter on ports.

I agree that there might be issues, and that an implementation would be
good...

Stig

---

From: Stig Venaas <[email-masked]>
Date: Tue, 19 Mar 2002 18:03:14 +0100

> temporary address allocation in standard DSTM can not satisfy th demand

I agree. I think one scenario for ports are home user (and maybe others)
that only get one IPv4 address. In that scenario I think a home router
box that has web proxy and DSTM+ports built in could be very useful.
Of course the box should also be a fully functional IPv6 router, that
should also include tunneling since the access network might be IPv4-
only.

Stig

---

From: Tim Chown <[email-masked]>
Date: Tue, 19 Mar 2002 17:56:57 +0000 (GMT)

> temporary address allocation in standard DSTM can not satisfy th demand

I appreciate the WG's desire to step up a few miles and take stock of all
drafts, but I would like to see the base DSTM draft go to WG Last Call
now.  We have implementations for at least Linux and BSD, and there is a
clear usage scenario for DSTM.

It woud be a signal to developers that it is a viable tool.  Jim pointed 
out that he expects production DSTM in 2002; I think a last call would 
help that development now, rather than stalling until July or later.  
The extensions presented in Minneapolis do need much more study, but the 
base spec seems sound.

On a deployment viewpoint, a MS implementation would be very useful, 
given we have good v6 app support in Linux and BSD.   Can any of the MS
people comment on their own plans here?

Thanks,
Tim