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

Re: WGLC ent-analysis-03: DSTM

On Fri, 19 Aug 2005, Francis Dupont wrote: 
    b.1) the set-up of the bidirectional v4-in-v6 tunnel with the tunnel
       server(s) which can happen without user intervention, e.g., using
       one of the processes described in
       draft-palet-v6ops-tun-auto-disc-03.txt.

=> note this I-D was submitted years after DSTM and is not a complete
solution (in fact, today it is not a solution at all :-).

Within an enterprise network (and having to discover v4-in-v6 TEP, so NATs are not an issue), the problem is much more constrained, so e.g., DHCPv6 is a possible solution. Softwires BOF might do something about this, or maybe not -- if folks are interested in this kind of problem, maybe they should speak up at a forum. In any case, the same approaches as are available for "DSTM" are probably also applicable here.

       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), I think it could basically be used itself, and for the service. Could you elaborate why you think it's inappropriate?

    b.2)  the automatic set-up of v4-in-v6 tunnels, so that between each
       host, an ad-hoc tunnel can be signalled and set up" [6to4-like
       traffic optimization]

=> I believe you have "direct tunnels" in the b.2 idea? 

Yes.

    c) assignment of an address on top of v4-in-v6 tunnel(s), but
       deferred until the application wants to create v4 socket.
       [issues with dual-stack server apps, for example]

=> note that c) is needed if allocated IPv4 addresses are global.
To come back to the DHCPv4 analogy, with DHCPv4 an address is needed
when a node attaches to the network, with c) an address is need
when (and only when) a node has to make an IPv4 communication.


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. Those which need them only now and then can also use global addresses, but the easiest would probably be using RFC1918 for those nodes.

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. Some may believe it's worth the effort; many others (like me) think it's not (and personally, I think it'll cause more harm than help).

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.

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

While c) may not conserve address space as effectively as c)+d), it's something to be evaluated based on the tradeoffs.

    - c) is something implementations may try to do on their own, but I
  would recommend against it, and the IETF shouldn't work on that

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

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

An analogue: when my DSL provider's DHCPv4 server goes down or the DSL modem's DHCP snooping breaks, my lease expires and on my BSD router the public v4 address I normally have is changed to "0.0.0.0". If I re-run DHCPv4, I get the address back. Why the same couldn't happen here? Why must the tunnel be removed?

  I have no problem having the enterprise analysis document include this
  kind of analysis, and describe the need for a) and b.1) -- and I think
  this is probably a good thing as it might lessen the confusion on the
  real requirements for v4-in-v6 tunnels -- but if we go further than
  that, we may have a problem....

=> we have already a problem with IPv4 global addresses: there are not
enough!

IANA has been allocating lots of /8's. Our organization has gotten a new /16 as well. I'd argue that the situation with v4 address availability has gotten better.

  > => the overload (if any) should be solved by the references...

  This is a working group document.  I don't think we can just refer to
  a non-wg, ambiguous document and expect it to clear up the ambiguities
  and confusion.

=> so your concerns are about the DSTM documents? 

You could say so, yes.

  > => I saw the birth of DSTM: DSTM is Jim Bound's AIIH + Laurent
  > Toutain's DTI.

  That may be, but many people since have used the term,

=> the term is not (yet :-) a trade mark...

  and may have zero idea what the goals are or may have been.

=> this is a random remark which is not about the WG I-D.

I think it may still be relevant, though. Lots of people who want just simple v4-in-v6 tunnels, or something slightly more sophisticated (for example a) and b.1) in above terminology) think they need something called "DSTM". Reading the spec does not give them much idea about the goals or the background relevant to their own requirements. The enterprise analysis document seems like a natural place to discuss these requirements in the hopes of lessening the confusion.

  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? Jeroen Massar also had done work in this space. Softwires BOF is working on this.

In any case, as far as I see, the DSTM spec is mostly just describing the concept and giving a couple of examples here and there which protocols could be used; I don't see how you could write an interoperable implementation based on it.

  What I meant is that if you already have a) and b.1), i.e., an ability
  for the host to set up a tunnel without manual configuration with a
  tunnel server, all your implementation needs to do is add a hack which
  triggers this activation when the v4 socket call is being made.

  There is no difference between b.1) and c) wrt. bits on the wire,
  right?

=> the difference between b.1) and c) is the type of IPv4 addresses.
If the IPv4 address can be statically allocated c) (and in fact b.1) too)
is not required, if the IPv4 address is global and cannot be statically
allocated (because the pool is too small), c) is required (and d) as
a consequence of c) too). 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 :-).

In any case, while different kinds of addresses used may or may not affect the weighing of tradeoffs, I don't see how b.1) and c) differ on the wire. The protocol to set up the signalling, the tunneling, etc. can be the same, i.e., there's no difference on the wire, and a decision could be just an implementation decision.

I'm not sure if there's anything requiring interoperability in d) either, as I guess you could just remove the tunnel interface if you don't have an address anymore -- I'm not sure if it's even worth the trouble -- but that's debatable.

  >   My point is that I'm having hard time figuring out:
  >     1) what the document means when it's recommending DSTM, and
  >
  > => the references

  As said, I don't think a wg doc like this can shrug off these kinds of
  issues by just referring to non-wg documents and letting them sort
  things out.  Best would probably be summarizing the different
  requirements or non-requirements (a-d above) in this doc, removing the
  references altogether, and enhancing the dstm spec (or writing a
  separate draft describing the scenarios/requirements for v4-in-v6
  tunneling) to try to remove any confusion.

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

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

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

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.

I'd be interested in seeing which kind of figures you have, could you send e.g., offlist if long?

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