Subject: [midcom] SPAN proposal

From: Melinda Shore <[email-masked]>
Date: Wed, 09 Oct 2002 10:45:23 -0400

Despite Pete's heroic efforts and several pieces of email
from one or two interested parties, we've failed to make any
progress at all on SPAN.  SPAN was intended to provide a
short-lived, temporary work-around until midcom becomes
available, and it's now looking like midcom may be complete
before SPAN (in any event, as things now stand we would
almost certainly not be able to complete SPAN before late
2003).  An additional problem is that by definition SPAN
provides a mechanism for users to circumvent local firewall
policy.

All in all the situation does not look promising.  I'd like
to propose that rather than continuing to allow SPAN to die
a lingering death we drop it from our deliverables.
Feedback, please.

Melinda
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: "Pete Cordell" <[email-masked]>
Date: Wed, 9 Oct 2002 17:10:13 +0100

Hi Melinda,

I'm afraid I've been quiet for a while because I was putting together a
document on existing techniques that could be used as an alternative to a
custom built SPAN protocol.  I've just sent this to the drafts editor, and
hopefully it will appear in the next few days.  Although there's a few
potential candidates (L2TP, IPsec, IP over IP, RSIP and Teredo (v4)), none
of them so far seem to meet the needs of SPAN.

I think SPAN is still worth working on for a number of reasons.

Firstly, your implication is that Midcom will be finished in 2003.  I'm
afraid I'm not that optimistic.  The evaluation document didn't pick a clear
winner, nor does it provide a mandate for developing a custom protocol.
There is probably many months of work to decide what to do, and then there
is the specific protocol work (whether SNMP MIBs etc, or custom protocol) to
be done.  Midcom's history would suggest this won't take place as fast as we
would like.

Secondly, even when Midcom does become available, it will have to work its
way into vendor builds, and then be enabled by customers.  This will
represent another couple of years.

Additionally, all this is exacerbated by the current economic situation that
you mentioned.  People are putting less effort into standards work, and less
effort into development.  Customers are being more careful about what they
invest in.  This will further push out the timescales of a Midcom protocol.

On the other hand, SPAN-A, with a few changes could be used almost
immediately.  Where possible it uses off-the-shelf technology, and (except
for TLS which you can get open source) is very simple.  Maybe it's more
appropriate to publish it as an experimental or informational RFC, but I
think making it available would be a great service to the community.

Finally, you mention the firewall issue.  What would enable SPAN to work
through an unmodified firewall basically amounts to a slack set of firewall
rules.  While such rules have been common in the past, such things have been
progressively tightened up over the years.  Indeed, there is no need for
such rules to be there, and they really shouldn't be there.  (In today's
virus infested world there's a very strong case for removing them
irrespective of whether SPAN exists.)  The main benefit of having a standard
is that there will only be one such solution, rather than half a dozen, and
vendors can block it out-the-box.

I therefore suggest that we carry on on a parallel development path as we
have been doing (although hopefully a bit faster!).

Pete.

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 9 Oct 2002 11:18:35 -0500

----- Original Message ----- 
From: "Pete Cordell" <[email-masked]>
> invest in.  This will further push out the timescales of a Midcom protocol.

People may be investing in things that work...with their existing investments...

128-bit DNS AAAA Record Flag Day Formats
2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
[YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
1-bit to set the Reserved/Spare ("SNOOPY") bit in Fragment Offset [S]
1-bit to set the Don't Fragment (DF) bit [D]
2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL]
1-bit for Options Control [O]
7-bits to set the Identification Field(dst) [FFFFFFF]
4-bits to set the TOS(dst) Field [TTTT]
Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000
FFF.FFFF.TTTT = GGG.SSSS.SSSS
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
IPv8
0QQQQGGGSSSSSSSS[32-bits][Port]
IPv16
0QQQQGGGSSSSSSSS[32-bits][Port]
1WWWWWWWSSSSSSSS[32-bits][Port]
====

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
http://www.ietf.com
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
http://ipv8.dyndns.tv
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://ipv8.myip.us
http://ipv8.dyn.ee
http://ipv8.community.net.au