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

From: "Christian Huitema" <[email-masked]>
Date: Sat, 21 Sep 2002 15:04:10 -0700

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

From:	 Hesham Soliman (EAB) [mailto:[email-masked]]	
Sent:	 Sat 9/21/2002 2:40 PM	
To:	 'Jun-ichiro itojun Hagino '; 'Erik Nordmark '	
Cc:	 [email-masked] '	
Subject:	 RE: (ngtrans) Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt 	

=> One question below

        if you have a node with:
        - dual stack support (kernel code supports IPv4 and IPv6)
        - RFC2553 with section 3.7 support (IPv4 mapped address)
        the node won't be able to interoperate with SIIT translator box.

        Let's say:
        - the node described above is A
        - SIIT translator is S
        - (IPv4) peer is X

        when incoming traffic from X via S reaches A, it will have IPv4
mapped
        address on source address field of IPv6 header.

=> Why are you using SIIT for this noe ???
I thought SIIT would be used if A was an IPv6-only
node.

Hesham

  it will get
delivered
        to userland application on A (*), and getpeername(2) will return
IPv4
        mapped address.  if the userland application try to respond to
this
        (A -> S -> X), it will try sendto(2) against IPv4 mapped
address,
        or TCP layer takes care of it.  since the destination address is
IPv4
        mapped address, RFC2553 section 3.7 kicks in, and the traffic
will
        go out of A as an IPv4 packet.

        (*) at this point, since IPv4 mapped address has dual use, I
would
        recommend rejecting the traffic to avoid abuses documented in
        draft-itojun-v6ops-v4mapped-harmful-00.txt.  if you follow this
        recommendation, A won't interoperate with S anyways.

itojun

---

From: [email-masked]
Date: Sun, 22 Sep 2002 10:47:27 +0900

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

	one of the point i was making (while it may not have been delivered
	well, sorry) is that we cannot make SIIT to use different prefix.
	SIIT is taking advantage of dual use of IPv4 mapped address.

	for instance, an SIIT-compatible IPv6 node in SIIT cloud will issue
	PORT/PASV request by seeing IPv4 mapped address on getpeername(2),
	and therefore, SIIT box doesn't need to translate the content of the
	packet.

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 23 Sep 2002 15:40:36 +0200 (CEST)

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

Please read section 1.3 in RFC 2765.

It states the reason for using the IPv4-mapped addresses and not something
else. Using a different prefix for SIIT would require that applications be made
SIIT aware; as the specification is written the applications merely have to be
dual-stack capable (i.e. aware that IPv4-mapped addresses refer to IPv4 peers)
for SIIT to work.

I'd agree that this is complex; perhaps too complex. 
Which is why the v6ops WG needs to look at which transition mechanisms
are truly needed.

  Erik