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

["Bound, Jim" <Jim.Bound@hp.com>]

I believe if a packet comes in with v4mapped then a flag must be set that SIIT is in process.  This was my recommendation on APIFOLKS a year ago.  If an app gets back a v4mapped and asked for it then that would be known too.

what we should do is document the cases that are not clear above.  But we cannot break the API.

I also believe of any NAT proposal I like and support SIIT since inception.
For what it is worth.

/jim

> -----Original Message-----
> From: Jun-ichiro itojun Hagino [mailto:itojun@iijlab.net]
> Sent: Tuesday, September 17, 2002 11:27 AM
> To: Erik Nordmark
> Cc: v6ops@ops.ietf.org; ngtrans@sunroof.eng.sun.com
> Subject: (ngtrans) Re: comments on
> draft-itojun-v6ops-v4mapped-harmful-00.txt 
> 
> 
> 	(since this is transition tool discussion replies to 
> ngtrans please)
> 
> >The assumptions behind SIIT is that the node is dual stack 
> (the protocols
> >as well as the applications) but the node  doesn't have a 
> permanent IPv4
> >address and the local network infrastructure does not support IPv4.
> >With those assumptions there aren't any strange requirements 
> on the devices
> >(ignoring the AH suggestion in the RFC:-); the ftp 
> implementation on a 
> >dual stack node already needs to support old stuff when 
> communicating with
> >IPv4 addresses.
> 
> 	if the above assumption is true, what do you intend to 
> do about the
> 	dual use of IPv4 mapped address?  telnet client on dual 
> stack machine
> 	would make a send(2) request to ::ffff:a.b.c.d, which 
> will be captured
> 	by an AF_INET6 socket, and goes out of the node as IPv4 packet.
> 	there's no documented way in which ::ffff:a.b.c.d would 
> go out as IPv6
> 	packet.  either RFC2553 API does not work, or SIIT dose 
> not work.
> 
> itojun
>