Subject: RE: (ngtrans) Re: comments on draft-itojun-v6ops-v4mapped-harmful -00.txt

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Mon, 23 Sep 2002 20:48:51 +0200

Catching up with this thread.

  > 	that's different from Erik says.

=> I don't think so, based on reading the last 2 days'
emails.

  > 
  > 	"kernel supports both IPv4 and v6" and "the system is 
  > configured for
  > 	dual stack operation" is different.  vendors may want 
  > to ship dual
  > 	stack all the time (to simplify support load), and the 
  > machine could
  > 	be put into SIIT environment (with no IPv4 address configured).

=> If there is no IPv4 address configured then I don't
think the v4 stack is active.

  > 
  > 	strange thing is that, to me, SIIT requires
  > 	- the kernel to be IPv6-only

=> _active_, yes. The kernel might have several
other stacks that are not active.

  > 	  (due to the conflict i outlined in the previous message)
  > 	- the userland application to be dual stack capable
  > 	  (to avoid protocol content translation in SIIT box)
  > 	which looks way too weird to me.  this is why i say 
  > SIIT is similar to
  > 	RSIP.

=> I don't really want to get into the RSIP part.
I just wanted to clarify that if the v4 stack is active
then the mapped address will become a v4 address on the
wire. If the v4 stack is not active (not assigned addresses)
then the mapped address is sent on the wire to an 
SIIT box. Of course the node's implementation has 
to be aware of how to understand the mapped address, but
I'm not sure that this is too complex, is it?

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Mon, 23 Sep 2002 21:34:07 +0200

I believe we have a general consensus in v6ops that prefixes are cheap while confusion is costly. It seems that we should simply allocate a different default prefix than ::FFFF:0:0/96 for the SIIT function. Something like 0:0:0:FFFF::/96, for example. This is a very simple update to SIIT, and it rids us of the confusion between the API spec, which is widely implemented, and SIIT, which is not. 

=> This would break the TCP checksums calculated 
in the v4 node. 

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 25 Sep 2002 11:18:27 +0200

> > 	- increased chances for security holes/interop 
  > issues/admin headaches
  > > 	so could we just agree on simple set of behavior (like 
  > "no IPv4 mapped
  > > 	address on wire") and move on?
  > 
  > Don't do it that way since it would mean that the IETF would have
  > two conflicting proposed standards; one which says to use 
  > the address on
  > the wire and one that says not to. That would be very confusing.
  > (Assuming there is rough consensus) the best approach would 
  > be to write
  > an explantory RFC which provides the motivation and move 
  > the SIIT specification
  > to HISTORIC.

=> I agree that the address allocation part is fairly complex
and in most cases (this is all speculative of course because
there are no real cases :) ) does not outweigh the advantages.
But I think that two benefits have not been discussed
so far:

- SIIT (with perhaps more stable address allocation) would
allow nodes that have MIPv6 implementations to communicate
with MIPv4 nodes. Of course without e2e RO but at least
they can communicate while moving. Some vendors seem to be
going to MIPv6 directly (no v4 implementation), so this
maybe attractive for a network where IPv4 addresses are not
scarce for MNs.

- Of course the translation algorithm is needed for 
NAT-PT.

I don't know what the demand is for the first point
but it is worth pointing out anyway. I think the second
point is important.

Hesham