Subject: RE: access to temp addrs in DSTM

From: "Bound, Jim" <[email-masked]>
Date: Tue, 10 Sep 2002 10:44:30 -0400

Pekka,

A bit of history.  DSTM was orginially called "Avoidance of Network Address Translation" (AATN) and a very specific solution.  We were asked to change the name to prevent negative connotation.  OK I did that.  We then combined forces with a Tunneling methodology from Laurent Toutain and company in the spring of 1999.  We had an AATN BOF in 98 and it was highly attended and spawned various activities like RSIP and a few others.  We then were asked to just build an architecture template and permit DSTM specific mechanisms as extensions to that main architecture.  There are extensions for Mobile IPv6, Use with SIIT, Port Ranges, and even 6to4 and all good engineering work.
So I feel I am very correct in arguing to the IETF DSTM is an architecture and method that folks do want in the IETF or there would not be so many adjunct extensions for DSTM.  In addition the NGTRANS Chairs supported this work and still do.  In addition there are three implementations currently of DSTM Francis spoke of ENST's, i2Soft, and the other is not annoucing yet but it is in Asia and for large Telecom doing Mobile IPv6.  i2Soft and the Asian Telecom are using DHCPv6 as a note.

So if anyone tells me that DSTM is not a needed and useful mechanism I simply cannot parse that at all.  Of if they try to second guess IPv6 deployment.

I think Tony Hain summed it up really well when he stated we need to complete the work on the Enterprise, UnManaged, and ISP ops design teams and see what we learn from those deployment works.

But to tell me and my authors and the NGTRANS working group after 3 years of hard work, support from the NGTRANS working group, trial deployment and some products in the market, that my colleagues who are very bright engineers are using DSTM to assist with things like SIIT, Mobile IPv6, and even the extensions to work with 6to4 that we have to go back to individual ID submissions is simply wrong and demonstrates that the IETF is being unfair, dicatorial without valid discussion in the community, and very well could justify the work to an appeal to the IAB and if necessary to the Internet Society.

This simply sounds like foul play and political efforts to kill DSTM and other mechanisms where motives are very unclear and they have not been able to kill it or prove it is wrong technically.  Thats what has me sketchy with the IETF OK.  Big time.

Lastly I don't agree with Francis at all and I believe the Port Range extensions draft for DSTM in fact is a very good piece of work and in fact will work and assist customers transitioning with DSTM.

regards,
/jim

> -----Original Message-----
> From: Bound, Jim 
> Sent: Tuesday, September 10, 2002 10:30 AM
> To: 'Pekka Savola'
> Cc: Jun-ichiro itojun Hagino; Brian E Carpenter; Fred L. Templin;
> [email-masked]
> Subject: access to temp addrs in DSTM
> 
> 
> Pekka,
> 
> As a note we made it clear in dstm that at this point one can 
> use any addr mgmt they choose to and will be specific specs 
> to be done for DSTM.  So if one want to use dhcpv4, or a 
> version of it, or RPC or DHCPv6 its pretty open.
> 
> /jim
>

---

From: Pekka Savola <[email-masked]>
Date: Wed, 11 Sep 2002 13:18:01 +0300 (EEST)

Trimmed Cc: list a bit.

On Tue, 10 Sep 2002, Bound, Jim wrote:
[...]
> So I feel I am very correct in arguing to the IETF DSTM is an
> architecture and method that folks do want in the IETF or there would
> not be so many adjunct extensions for DSTM.  [...]

Why not make the IPv4 address management (a bit more clearly perhaps) a 
bit more clearly a replaceable part of the architecture?

Mainly my objection is that the DSTM model as I see it is using v6-only
network and tunneling IPv4 over that (when necessary).  "When necessary"  
varies greatly between people deploying DSTM.  For example, one company
here with an IPv4 assignment of /16 with 4000 nodes may be interested in
something similar; it is possible that some folks do not see the IPv4
shortage as direly as others, and may want to use some other mechanism for
handling IPv4 addresses (static assignment, DHCPv4, whatever).

That's IMHO the simplest and the most "robust" and "stable" case (==
requires no code at all I think).  More complex mechanisms (like using 
RPC, or whatever) may be warranted, but these should be an extension.

Perhaps this clarifies how I feel about the architecture or DSTM framework 
if I may.

[...]
> I think Tony Hain summed it up really well when he stated we need to
> complete the work on the Enterprise, UnManaged, and ISP ops design teams
> and see what we learn from those deployment works.

Indeed.

[...]
> Lastly I don't agree with Francis at all and I believe the Port Range
> extensions draft for DSTM in fact is a very good piece of work and in
> fact will work and assist customers transitioning with DSTM.

Port Range extension is an interesting idea, but I have great doubts on 
the robustness.  In particular, I don't see any way the node could 
reliably control that an application doesn't just use any port it wishes 
to use regardless of the assigned ports.  It may be useful in some very 
restricted cases, but probably not so in general.

-- 
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