Subject: (ngtrans) Shipworm obfuscation

From: "Michael Cole" <[email-masked]>
Date: Thu, 26 Sep 2002 23:17:21 -0400

Why not have a flag bit that indicates whether the address are in their 
normal state or in the 1s complement state? Seems to me that there are enough 
flag bits to do this. This way, 80% or whatever instances of Shipworm will be 
easier to debug. It would also make a unified Shipworm+Isatap+6to4+6over4 box 
easier to implement.

--- Michael Cole

--- [email-masked] 

--- EarthLink: It's your Internet.

---

From: "Michael Cole" <[email-masked]>
Date: Sun, 29 Sep 2002 1:42:27 -0400

What I meant by a unified standard is that we have a set of problems where 
in order to translate an IPv4 address we also have to incorporate the port 
number. Shipworm is a good start, but I believe that it can be made into 
something more versatile to get around the problem that in some instances 
besides NATs, the port number has become a 16-bit extension of the IPv4 
address.

Usually, the only way to recan a can of worms is to use a bigger can. NATs 
and RFC 1918 have created these kinds of problems. For instance, the RFC 3056 
could be used with the Isatap suffix so as to concatenate a global IPv4 and a 
local IPv4, but that does not help when the port number must or should be 
incorporated in order to get the work done.

The other problem is that the BIGGEST obstacle to deployment of IPv6 is 
that most corporations want experience and they want people to get experience 
from an invisible gremlin named Not Me. It is going to take 15 years to overcome 
that obstacle. Any transition mechanism needs to be durable and has to get 
around IPv4 hardware and software that somebody refuses to replace because 
there are not enough experienced IPv6 people. I have seen a major company 
(Alcoa) spend $100,000 on recruiting costs in order to avoid $10,000 in training 
costs.

----- Original Message ----- 

From: Bound, Jim  

To: Fred L. Templin ;Michael Cole 
Cc: [email-masked] 

Sent: 9/29/2002 12:52:22 AM 

Subject: RE: (ngtrans) Shipworm 
obfuscation

I 
would not assume we will get a unified box from the thought.  I believe 
doing a spec is fine.  I am not clear it is needed for a supplier to 
implement all this in a box and most likely by the time it was defined ISATAP, 
6to4, and Teredo will be deployed.  6OVER4 is DEAD.  Not enough users 
use multicast in IPv4 to warrant the business investment is my reading for 
products I work on.

/jim

-----Original Message-----
From: Michael Cole 
[mailto:[email-masked]]
Sent: Friday, September 27, 2002 11:40 
PM
To: Fred L. Templin
Cc: 
[email-masked]
Subject: Re: (ngtrans) Shipworm 
obfuscation

A unified box definitely would make some things easier. Between the matter 
that cable ISPs have been using NATs and some wireless access points can engage 
in NAT-like behavior, there is the possibility of LAN-to-LAN NATs. Same for 
encryption boxes on LAN-to-LAN links. The protocol unification would have to 
provide for either coping with double NATting or having a way to avoid it or 
both.

Where there is a possibility of a long term island or isthmus of IPv4 
connectivity are things like wireless nodes and encryption boxes especially 
since the integrated circuit lifetime problem was solved starting with the 386. 
I have seen early LSI chips last about as long as industrial vacuum tubes.

----- Original Message ----- 

From: Fred L. 
Templin  

To: [email-masked] 

Sent: 9/27/2002 7:36:15 PM 

Subject: Re: (ngtrans) Shipworm 
obfuscation

Michael Cole wrote:

  It would also make a unified

  Shipworm+Isatap+6to4+6over4 box easier to implement.

                        ^^^^^^

I'm glad you mentioned this, because 6over4 seems to be getting lost 
in

the shuffle here as we discuss other mechanisms. I agree that a 
unified

solution is what we're after, but I would rearrange your grouping 
above

somewhat differently as follows:

   unified_solution = (6to4 + (teredo + isatap + 6over4))

Since 6to4 provides the global solution and the other mechanisms 
contribute

various aspects to the local solution, the "unification" really only needs 
to

occur among the components in the inner parentheses. I am all for 
unification,

but have sensed some resistence in others; perhaps the only bone of 
contention

is what to call the unified thing?

I have an idea: why don't we just do a (bis) on RFC 2529 and merge 
the

necessary features from teredo and isatap in with the existing 
features

of 6over4?  Then, just as it was in the old days:

   unified_solution = (6to4 + 6over4)

If this would make everyone happy, then maybe we can finally work 
together

on the details of the unification in a spirit of cooperation.

Comments?

Fred

[email-masked] 

--- Michael Cole

--- [email-masked] 

 

--- Michael Cole

--- [email-masked]

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 29 Sep 2002 15:51:37 -0700

I don't see how your message answers the first question we should ask before any new work:
"what are the scenarios in which a unified solution would be more useful than several separate
solutions?"
 
  _____  

From:	 Michael Cole [mailto:[email-masked]]	
Sent:	 Sat 9/28/2002 10:42 PM	
To:	 ngtrans	
Subject:	 RE: (ngtrans) Shipworm obfuscation	

What I meant by a unified standard is that we have a set of problems where in order to translate an IPv4 address we also have to incorporate the port number. Shipworm is a good start, but I believe that it can be made into something more versatile to get around the problem that in some instances besides NATs, the port number has become a 16-bit extension of the IPv4 address.
 
Usually, the only way to recan a can of worms is to use a bigger can. NATs and RFC 1918 have created these kinds of problems. For instance, the RFC 3056 could be used with the Isatap suffix so as to concatenate a global IPv4 and a local IPv4, but that does not help when the port number must or should be incorporated in order to get the work done.
 
The other problem is that the BIGGEST obstacle to deployment of IPv6 is that most corporations want experience and they want people to get experience from an invisible gremlin named Not Me. It is going to take 15 years to overcome that obstacle. Any transition mechanism needs to be durable and has to get around IPv4 hardware and software that somebody refuses to replace because there are not enough experienced IPv6 people. I have seen a major company (Alcoa) spend $100,000 on recruiting costs in order to avoid $10,000 in training costs.

	----- Original Message ----- 
	From: Bound, Jim <mailto:[email-masked]>  
	To: Fred L. Templin <mailto:[email-masked]> ;Michael Cole <mailto:[email-masked]>  
	Cc: [email-masked] <mailto:[email-masked]> 
	Sent: 9/29/2002 12:52:22 AM 
	Subject: RE: (ngtrans) Shipworm obfuscation

	I would not assume we will get a unified box from the thought.  I believe doing a spec is fine.  I am not clear it is needed for a supplier to implement all this in a box and most likely by the time it was defined ISATAP, 6to4, and Teredo will be deployed.  6OVER4 is DEAD.  Not enough users use multicast in IPv4 to warrant the business investment is my reading for products I work on.
	 
	/jim

		-----Original Message-----
		From: Michael Cole [mailto:[email-masked]]
		Sent: Friday, September 27, 2002 11:40 PM
		To: Fred L. Templin
		Cc: [email-masked]
		Subject: Re: (ngtrans) Shipworm obfuscation

		A unified box definitely would make some things easier. Between the matter that cable ISPs have been using NATs and some wireless access points can engage in NAT-like behavior, there is the possibility of LAN-to-LAN NATs. Same for encryption boxes on LAN-to-LAN links. The protocol unification would have to provide for either coping with double NATting or having a way to avoid it or both.
		 
		Where there is a possibility of a long term island or isthmus of IPv4 connectivity are things like wireless nodes and encryption boxes especially since the integrated circuit lifetime problem was solved starting with the 386. I have seen early LSI chips last about as long as industrial vacuum tubes.

			----- Original Message ----- 
			From: Fred L. Templin <mailto:[email-masked]>  
			To: [email-masked] <mailto:[email-masked]> 
			Sent: 9/27/2002 7:36:15 PM 
			Subject: Re: (ngtrans) Shipworm obfuscation

			> Shipworm+Isatap+6to4+6over4 box easier to implement.
			                        ^^^^^^
			I'm glad you mentioned this, because 6over4 seems to be getting lost in
			the shuffle here as we discuss other mechanisms. I agree that a unified
			solution is what we're after, but I would rearrange your grouping above
			somewhat differently as follows:

			Since 6to4 provides the global solution and the other mechanisms contribute
			various aspects to the local solution, the "unification" really only needs to
			occur among the components in the inner parentheses. I am all for unification,
			but have sensed some resistence in others; perhaps the only bone of contention
			is what to call the unified thing?
			 
			I have an idea: why don't we just do a (bis) on RFC 2529 and merge the
			necessary features from teredo and isatap in with the existing features
			of 6over4?  Then, just as it was in the old days:

			If this would make everyone happy, then maybe we can finally work together
			on the details of the unification in a spirit of cooperation.
			 
			Comments?
			 
			Fred
			[email-masked]

		 
		--- Michael Cole
		--- [email-masked]

--- Michael Cole
--- [email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 30 Sep 2002 13:37:30 -0700

Christian Huitema wrote:
 > and 6over4 is essentially dead

Bound, Jim wrote:
 > 6OVER4 is DEAD.
 > Not enough users use multicast in IPv4 to warrant the business
 > investment is my reading for products I work on.

There is (at least) one aspect of 6over4 which can provide benefit to future
deployments in mobile ad hoc wireless networks, which will almost certainly
deploy IP multicast as a standard feature. I have previously expressed my
opinion on this subject in a draft entitled: "Fast Convergence Extension for
ISATAP Router Discovery". See:

  http://www.ietf.org/internet-drafts/draft-templin-ngtrans-isatapext-00.txt

Very basically, studies have shown that power savings and convergence time
tradeoffs exist between base station beaconing and mobile node polling for
topology discovery (see proceedings from MobiHoc 2000.) If the mobile nodes
poll continuously while base stations remain silent, they burn their batteries.
If instead the base stations send periodic beacons, the mobiles can take better
advantage of hibernation modes to save their batteries. Since the base stations
must beacon periodically, the beacons might as well carry 6over4-encoded RFC
2461 Router Advertisements so that mobiles can gain some cursory knowledge of
the topology they encounter. (NOTE: the document I mentioned above needs to be
revised to discuss authentication mechanisms for mobiles to associate with
such beaconing base stations.)

So, the multicast beaconing mechanisms of 6over4 arguably have potential
future use. But, the ground-breaking precedent set by 6over4 should also
be honored in some way, IMO. Even if we just took the title and some rough
structure from the existing document in a (bis), I feel it would give proper
acknowledgment to  the past works of others. Plus, the names currently used
by some of the other mechanisms we've talked about leave *alot* to be desired.
I'm not in love with the name ISATAP, and I'm terrible at coming up with new
names as someone else observed. Also (and I hate to say this, Christian), I
just can't see myself 3 years from now telling a network engineer to
"Go check the TEREDO Relay".

Fred
[email-masked]

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 30 Sep 2002 14:31:09 -0700

> If instead the base stations send periodic beacons, the mobiles can
take
> better
> must beacon periodically, the beacons might as well carry
6over4-encoded
> RFC
> 2461 Router Advertisements so that mobiles can gain some cursory
knowledge
> of
> the topology they encounter. (NOTE: the document I mentioned above
needs
> to be

You are making a case for adding an optional "RA multicast" to ISATAP.
It makes sense to support this facility when IPv4 multicast is
available, and the implementation cost is modest. There is a big
difference however between an optional RA multicast and a complete
reliance on IPv4 multicast for neighbor discovery. 

By the way, you should really how much data can be multicast efficiently
on a cellular network. We are observing that the quality of multicast
transmission over radio links is often very poor, especially if the
message requires more than one low level frame. The amount of data that
can be piggybacked on a wireless beacon is probably quite limited; a
simple RA may or may not fit, and you certainly won't have much space
for more data.

> by some of the other mechanisms we've talked about leave *alot* to be

Acknowledging the work of other is fine and ethical, but the proper
procedure is by means of citations in the reference section and the
acknowledgement section.

The name ISATAP has the big advantage of avoiding consonance with the
name 6to4, and thus avoiding confusion. 

> I'm not in love with the name ISATAP, and I'm terrible at coming up
with
> new
> names as someone else observed. Also (and I hate to say this,
Christian),
> "Go check the TEREDO Relay".

Teredo is a temporary transition mechanism. We may be still using it 3
years from now, but I hope that 5 years from now it will be gone. That
being said, the wrong part about "checking the Teredo relay" is not the
name, but that we have to check in the first place. What we should do
is: remove as many as possible of the "reasons to check". This is true
for pretty much everything we do...

-- Christian Huitema