Re: WGLC ent-analysis-03: DSTM

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   >        This must include a way to auto-configure a v4 address [e.g., DHCPv4].
   >
   > => I believe you mean something providing the same service than DHCPv4,
   > not DHCPv4 itself.
   
   While DHCPv4 may or may not require minor tweaks (e.g., relating to 
   link-layer adaptation),

=> using DHCPv4 over a tunnel is *not* a minor tweak.

   I think it could basically be used itself, and for the service.

=> unfortunately this is not true. BTW the code itself can be reused
but this is not the case of the protocol.

   Could you elaborate why you think it's inappropriate?

=> DHCPv4 can't send a packet over a tunnel which has no addresses,
the limitation comes from DHCPv4 itself and from the nature of tunnels.
But as I've explained this is not dramatic: we already have the code
which provides the service, we only need to add some glue to replace
the protocol, or if you prefer this way a small facility for carrying
DHCPv4 messages and a translator (better if you can only reuse the
binary of the server).
   
   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.

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

   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?

   I gave further reasons for my belief in my reply to Stig on Aug 10, 
   with subject "Re: Enterprise Analysis DSTM Issue: dynamic setup", 
   especially wrt. who needs a global or private address.
   
=> I should have this message somewhere in my mail box.

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

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

   While c) may not conserve address space as effectively as c)+d), it's 
   something to be evaluated based on the tradeoffs.
   
=> in the DSTM context, we already studied what should be the size
of the pool and the lifetimes (initial/renew) from statistics about
some real traffics (it was a good subject for a student training period).

   > => c) is *not* an option when you have not one address per node, i.e.,
   > when b.1) is not usable.
   
   I'm not sure what you meant with "is *not* an option".  What is the 
   option then?
   
=> not c), i.e., I've tried to mean that c) is required and not optional
in this case.

   >     - d) doesn't seem to be worth the effort and is probably difficult to
   >   get right -- and for addresses, DHCPv4 and other methods already
   >   exist; not sure we want/need to do more work on that.
   >
   > => perhaps I have misunderstood d) but when the IPv4 address expires the
   > tunnel must be torn down...
   
   No, I don't think it follows.  I don't see why you couldn't just have 
   a v4-in-v6 tunnel but the host wouldn't have any v4 address, right?
   
=> I don't know how to easily implement tunnels without addresses...
But this is an implementation detail, i.e., you can disable the tunnel
in place of deleting it.

   >   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?
   
   > BTW you could say that a NAT removes the
   > requirement but I don't think you'd like to use this argument.
   
   In fact, I *do* like to use that argument :-).
   
   > => so you ask for a scenario with global IPv4 addresses (c)) or
   > for clear operational advantages for (c)).
   
   I'm only looking for the second, because the first may or may not call 
   for this scenario.
   
=> IMHO the first one is better even I nearly used DSTM for the second.

   > IPv6-dominant networks (section 6) are the reason to ask for at least a),
   > the text ("must acquire...locate...") suggests at least b.1).
   > It seems I have now a clear view of the "missing part" in the WG I-D...
   
   yes, and these must be clearly separated from each other, especially 
   if there is a scenario calling out for c) or d).
   
   > I propose this scenario:
   > - an IPv4 site with 200 nodes using a /24 is connected to the Internet.
   > - the site grows to 500 nodes, solutions are:
   >   * get more IPv4 addresses: I suppose it is not possible.
   >   * put a NAT: I suppose we don't want this!
   >     Note a NAT on addresses only should be enough.
   >   * switch to IPv6, get a /48, take advantages of IPv6 feature, etc,
   >    but what to do with partners (perhaps including the ISP :-) still
   >    using IPv4: lookup for the solution in the WG I-D?
   > - I assume there is a reasonnable number of "simultaneous" nodes which
   >   need an IPv4 address from the /24 pool. This assumption is used for
   >   the NAT or the DSTM solution (I have real world figures to support
   >   this assumption).
   > - the best solution is DSTM...
   
   Frankly, the dominant v6 deployment for this problem seems like 
   shooting birds with 160mm cannon (much much trouble that way), but 
   that aside..
   
=> 160mm? Too small! (:-).

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

   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.

   I'd be interested in seeing which kind of figures you have, could you 
   send e.g., offlist if long?
   
=> the study was paid by a commercial ISP...

Regards

Francis.Dupont@enst-bretagne.fr