Subject: v4-mapped-v6 addresses with SCTP Sockets API.

From: Jon Grimm <[email-masked]>
Date: Tue, 05 Nov 2002 16:58:57 -0600

Might as well dump out another I-D issue, so we can get them into the
next I-D if needed:

Concerning "v4-mapped-v6" addresses and SCTP Sockets Extensions:

The latest drafts for the SCTP sockets extensions do not say anything to
v4-mapped-v6 addresses.   Previous drafts had said very little, except
in the socket(PF_INET6) having some words of :

"The syntax is,

     sd = socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP);

    or,

     sd = socket(PF_INET6, SOCK_SEQPACKET, IPPROTO_SCTP);

    Here, SOCK_SEQPACKET indicates the creation of a UDP-style socket.

    The first form creates an endpoint which can use only IPv4
    addresses, while, the second form creates an endpoint which can use
    both IPv6 and IPv4 mapped addresses.
" 

(Yes, I had to dig back a ways to find it, but I knew the words were
there at one point in time).  The words were changed from "IPV4 mapped
addresses" to "IPv4 addresses".  

The IPV4-mapped address words have been changed (for some time), but I
don't have the context for the change.   Are v4-mapped-v6 address just
an implied part of the API?  Or does this imply the opposite, that they
should not be supported for SCTP PF_INET6 applications?   

Note:  I realize v4-mapped-v6 are completely disallowed within the SCTP
protocol; my question is specifically on how to handle PF_INET6 clients
at the API layer.  

As it is currently, stands my interpretation is:
 PF_INET sockets, AF_INET addresses:  v4 addresses  
 PF_INET6 sockets, AF_INET6 addresses:  v6 or v4-mapped addresses

My view is such as it preserves the presently expected behavior for
PF_INET6 applications needing to interact with a v4 peers.  This would
include msg_name for recvmsg/sendmsg calls. 

However, there are new API issues with the SCTP extensions:  For
example,
bindx() and various events use "struct sockaddr_storage".   Should a
PF_INET6 socket use AF_INET6 addresses exclusively, or should we allow
either?  Its easy enough to allow either as input to sockets, but how
about for output (e.g. events)?   Should we specify AF_INET6 only, or
make the application expect either (AF_INET v4 address or AF_INET6
v4-mapped-v6 address).  

Yes, this is probably a very minor issue, but I'd like to get this
nailed down for expectations by PF_INET6 application writers, so they
don't tie themselves in early to any certain implementaion choice.  

Some options:
1) No v4-mapped-v6 addresses allowed!
2) PF_INET6 addresses exclusively use AF_INET6 address format (v4
addresses come in/out as v4-mapped-v6 only)
3) Specify some hybrid behavior in the I-D.  Minimally, I'd expect to
see what the application can expect on output.
3) Anything goes!  Application is required to expect addressing format
for V4 addresses in either format.    

Opinions?  

Best Regards,
Jon Grimm

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Tue, 19 Nov 2002 09:25:02 -0600

Jon:

Some comments from a boring bof :->

>should not be supported for SCTP PF_INET6 applications?   
I don't think that it is NOT supported... but implied as to the way you
want to do it..

In our implementation:

- A IPv4 address can be sent to a IPv6 address (assuming you have not
  set the V6_ONLY flag on the socket). Or if you prefer you can send to
  a mapped V4 address and the stack will convert it to V4...

- In reading an address... if someone sends to you from an IPv4 address
  you will read from your IPv6 socket one of two things... either a true
  IPv4 address OR a IPv4 mapped address. This is dependant on a flag
  that we put in the API. The default is you get IPv4 addresses as IPv4 
addresses...even
   though this does not coorespond to the v6 api spec... (if you want 
that you turn on
  the flag).

My personel opinion as always been that it made no sense to have a V6 
socket that you
the app had to (on send):

1) Convert V4 address to mapped V6
2) pass to kernel
3) kernel convert V6 address to V4
4) then process.

And on rcv

1) Kernel does processing
2) Kernel converts to mapped v6 address sends to user
3) User reads
4) User converts to V4 address.

This just all seemed like an extra waste of cycles... so Peter and I 
decided to

a) make the above work for the pureist
and
b) allow a user to send v4 and v6 addresses down and based on our api flag
    rcv either a mapped or pure v4 address.

I felt this was a good approach and I did not want the sockets draft to 
force
one to do it a specific way but leave it open... this is why I changed 
the wording
of the only place (amongst several others that it was not specified) to 
the wording
you note.. this

a) keeps it consistent in the document
and
b) leaves the implementation wiggle room to do either method or both :>

> PF_INET6 sockets, AF_INET6 addresses:  v6 or v4-mapped addresses

And the wording of the document completely allows the above but it also 
allows
     PF_INET6 sockets, AF_INET6 addresses v6 or v4-mapped PLUS v4 
addresses...

>include msg_name for recvmsg/sendmsg calls. 

Yes this was our point.. preserve the apps view but in reality what most 
apps
do (I know from my recent ports of some of the v6 capable apps)

a) read in to a sock_storage (or equivialant)
b) look at the type... if it is v4 process it as that
c) if it is v6 see if it is mapped... if so change it to
   v4 and process
d) else process as v6.

That way the same code can deal with v6 or v4 sockets...

I like our solution.. you can have it either way you want it.. restrict 
reads to
only mappedv4 or get real v4... application choice...

>either? 

I think you must allow a mapped v4 address in the bindx.. unless you have
turned on a V6_ONLY flag (if your O/S has this). In our implementation
unless the V6_ONLY flag is set we will accept (on a PF_INET6 socket)
a) v6 address
b) v6 mapped v4
or
c) v4 addresses

in ALL cases..

> Its easy enough to allow either as input to sockets, but how
I would like to leave it as it is.. aka unspecified..

The documetn as I have said allows wiggle room..

>Some options:
>1) No v4-mapped-v6 addresses allowed
>
Right now the document leaves it open.. but we may want to put
some minor text in that specifies that a applicaiton should
always have the ability to assure all v4 addresses are mapped if
we have a v6 socket...

That way an app COULD be written to deal with v6 only address styles ** 
a poor
design in my mind ** but we can allow bad designs too :-)

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)

---

From: Jon Grimm <[email-masked]>
Date: Tue, 19 Nov 2002 10:45:56 -0600

Hi Randy,

Spec'ing a mechanism to set/get behavior seems reasonable, though the
choice of default is arguable given RFC 2553 expectations.  

OTOH, from your porting experiences it doesn't sound like application
are really taking advantage of v4-mapped-v6 addresses in a way to
consolidate their code.  Is this likely due to the application still
needing to support PF_INET only systems?  That darn reality just keeps
creeping in, don't it? 

I'll watch for a mechanism (I'm assuming sockopt here.) forthcoming.  A
recvmsg flag seems overkill as an application would surely just want one
addressing format.   

Best Regards,
Jon

> Some comments from a boring bof :->

<much clipped>