RE: access to temp addrs in DSTM

["Bound, Jim" <Jim.Bound@hp.com>]

Hi Pekka,

The DSTM draft-ietf-ngtrans-dstm-08.txt permits the use of the address mgmt that you want and I suppose doing a draft with dhcpv4 to obtain the addreses is fair.  I would support it as engineer even though I don't like the idea.

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: Wednesday, September 11, 2002 6:18 AM
> To: Bound, Jim
> Cc: v6ops@ops.ietf.org
> Subject: RE: access to temp addrs in DSTM
> 
> 
> 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?

We took address mgmt out of the architecture I think that was wise.

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

Then what you are debating is our assumptions not our technical work.  I believe that to be as important discussion as the technical giblets suggested.

We built DSTM for dominant IPv6 backbones that is what it is for not for IPv4 backbones.

For the scenario above the user may have enough address space (globally routable I will assume) that to connect with IPv4 apps they do not have to manage IPv4 as scarce resource.  THen I would argue for that case DSTM is not needed.

Our work was for users who do have to treat their IPv4 global routable address space as a scarce resource.  It also assumed many of the users were having to use NAT with private address space.

Hmmmm.  This we could state much clearer in our DSTM assumptions section.  So this conversation to me just found a hole we need to state.

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

Hmmm.  I will have to go read the draft but controlling evil apps is something we could do in that extension.  But I believe it to be useful because for a user that only has lets say 10,000 IPv4 global address spaces distributed across a multi-sited Intranet the port ranges can help with conservation.

I do agree with restricted cases but maybe not on the word "restricted".  I believe in Caveat Emptor and survival of the fittest.  Clearly a minority view in this community.
But on the other hand we cannot protect every case from happening or we won't ship specs.  We have to assume that the majority of implementors, operators, and users are intelligent beings educated about doing networking.  I am fine with that assumption.

thanks
/jim

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