[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WGLC ent-analysis-03: DSTM

On Mon, 22 Aug 2005, Francis Dupont wrote:
=> using DHCPv4 over a tunnel is *not* a minor tweak. 

Creating a separate thread out of this.

  No, "global v4 addresses -> c)" does not follow.

  It is a perfectly fine way to run and use addresses to give each node
  requiring v4 connectivity a static global address.

=> you only assume that anybody has already enough global addresses.
I'd like that it is true but in fact it is not.

I think you're assuming that everyone with [not "enough", i.e., basically everyone] global v4 address will want c) as a consenquence. I disagree with that.

I agree that some might see c) as a potential solution. A subset of those might even think c) is worth the trouble. But it is IMHO too wide a generalization to just say "global v4 addresses -> c)".

  Those which need
  them only now and then can also use global addresses, but the easiest
  would probably be using RFC1918 for those nodes.

=> RFC 1918 and a NAT? Is it really your idea?? 

Yes.  People use it, and seem to be pretty happy about doing so.

Remember, we're offering *v6* as an end-to-end protocol which doesn't have to deal with NAT etc. In that light providing this functionality for v4 might even be counterproductive :)

  The issue how aggressively to conserve v4 address space at the cost of
  more complexity and mechanisms like dynamic assignments/removals is a
  trade-off.

=> Do you argue there is not realistic scenarios where there is no
choice and the IPv4 address space has to aggressively be conserved?

No, I'm not saying that. What I'm saying is that people will use different (simpler) tools to perform this conservation. The easiest one at their disposal is RFC1918 and NAT. At some circles, you just apply for more address space, depending on the amount of pressure you can puton your hostmasters (and the size of assignment window right now etc.), you could also get more space to mitigate the need.

My argument is that let people use RFC1918, NAT, or whatever mechanisms they want for *v4* address conservation, let us focus on *v6* transition, not finding means how to prolong v4 address usage under aggressive conservation.

  >     d) automatic monitoring and tear-down of said v4-over-v6 tunnel(s)
  >        when the host detects it no longer needs the address/connectivity
  >
  > => as I've already explained, d) is a consequence of c).

  While d) may be desirable by some if you want to release the global
  address back to the "pool" as soon as possible, it's not a direct
  consequence AFAICS.

=> it is a direct consequence of the not unlimited lifetime of
the allocation.

No -- getting an address and keeping it until the node is rebooted (or some other similar event, e.g., DCHPv4-like lease expires or whatever) fulfills that criteria -- the lifetime *is* limited, right?

What you want is to get the addresses back to the pool as early as possible, to ensure the most efficient use of address resources. But while that may be your goal, I'm trying to make it clear that there may be people just wanting c), not d).

  It'd be perfectly fine to deploy only c) with the
  assumption that if the host needs v4 even once, it gets v4 "for good"
  (at least as long as isn't rebooted).

=> allocations with an unlimited lifetime are not enough aggressive.
(this is why BOOTP was extended to DHCP).

But e.g., DHCP-like mechanisms with lease times do have a limited lifetime, right?

Maybe d) could be split off to something like:

     d.1) automatic monitoring and tear-down of said v4-over-v6 tunnel(s)
        when an address lifetime expires (and is not renewed)

     d.2) automatic monitoring and tear-down of said v4-over-v6 tunnel(s)
        when the host detects it no longer needs the address/connectivity

(I don't see how the host checks that it no longer needs the address in d.2 but that's a separate point -- or how you'd prevent premature revokation of the address w/ a lifetime..)

I think you are proposing something that seems to significantly differ from what has been deployed today: DHCPv4 is typically used to give you an address "for good" (to be refreshed periodically though). It doesn't have provisions (AFAICS) to detect whether the address is in use or not when deciding whether to try to refresh the lease or not. You're adding a component of potentially fragile nature in the system.

  >   Certainly, if you wanted to create ad-hoc tunnels (6to4-like) between
  >   each host or the like, a protocol interoperability that goes beyond
  >   the plain tunnel broker would be needed.  But I wasn't implying that
  >   functionality (nor do I think it is needed).
  >
  > => what I said is the setup mechanism is orthogonal to the tunnel
  > mechanism and the only thing about it is just to have one (zero
  > doesn't work, two or more don't interoperate). BTW to be clearer
  > here I mean the setup of a tunnel between a node and a TEP.

  Well, isn't TSP a solution here as well?

=> DSTM can use TSP (there is a discussion about the choice between
TSP and DHCPv6, both work but we need one and only one :-).

  I don't see how you could write an interoperable implementation
  based on it.

=> I was able to write one so I could?

See above -- there are lots of places where multiple solutions could be used; if you pick A, you won't interoperate with other implementations which have chosen B.

  What are the chances that such a site is not already using NAT, or
  doesn't have the capability of getting more addresses?

=> this is not (yet?) the place where to explain why NATs are bad.
Just say there is a binary only application using embedded addresses
(unfortunately not a silly assumption, don't forget this is about
enterprise scenarios).


Such applications likely work fine through a TCP proxy or NAT?

  In university world, lots of places actually use mostly global v4
  addresses, but on the other hand, they also seem to be quite capable
  of obtaining more from their LIRs and RIR as needed.

=> here I ask my site administrator a /24 or /25, I've still waited
for some years, so don't say this is easy everywhere because it is easy
where you are, PLEASE.

Maybe you should escalate the issue to your site administrator's boss through your boss. Quite often, the need is not considered significant enough, folks figure out different solutions, or you get more addresses.

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