Subject: Re: New "IP Version 6 Addressing Architecture" draft

From: Jack McCann <[email-masked]>
Date: Fri, 14 Jul 2000 12:13:01 -0400 (EDT)

During w.g. last call, I suggested a change of wording in the
definition of IPv4-mapped addresses (mail attached below).  I
see the suggestion was not incorporated in addr-arch-v3-01.
Let me offer an example of what motivated my suggestion.

Suppose we have 2 IPv6/IPv4 nodes: Node A has IPv6 address A::A
and IPv4 address 1.2.3.4.  Node B has IPv6 address B::B and IPv4
address 5.6.7.8.  Node A is running a server which is listening
for both IPv4 and IPv6 connections on an AF_INET6 socket.  A client
on node B connects to node A's IPv4 address (1.2.3.4), with packets
sourced from B's IPv4 address (5.6.7.8).  (Why does the client use
A's IPv4 address?  Perhaps it is an AF_INET application that has
not yet been upgraded, or perhaps the user entered 1.2.3.4.)  The
server on node A accepts the connection, and because it is using
AF_INET6 sockets, accept() returns B's IPv4 address as ::FFFF:5.6.7.8.
In this example, an IPv4-mapped address (::FFFF:5.6.7.8) is used
to represent the address of an IPv6/IPv4 node (B).

Is this correct usage of IPv4-mapped addresses?  Or is it a violation
of the architecture?

- Jack

------------------------------------------------------------

---

From: [email-masked]
Date: Fri, 21 Jul 2000 20:18:19 +0900

>Let me offer an example of what motivated my suggestion.

	maybe it is too late, but I do have a comment on addr-arch-v3-01.
	I presented the issue at the previous IETF.

	addr-arch-v3-01 is silent about what is the legal use of IPv4
	mapped address.  RFC2553 suggests to use it as node-internal
	identifier for IPv4 destination, and SIIT draft suggests to use
	it on the wire in IPv6 headers.
	because the address can be used for two meaning, we have possible
	security issue if we try to support RFC2553 AF_INET6 special behavior.

	please refer to draft-itojun-ipv6-transition-abuse-01.txt, specifically
	section 3.  my suggestion is to forbid IPv4 mapped address in the IPv6
	headers, and remove ambiguity from the dual use.

itojun

--- excerpt
3.  Abuse of IPv4 mapped address

3.1.  Problems

IPv6 basic socket API [Gilligan, 1999] defines the use of IPv4 mapped
address with AF_INET6 sockets.  IPv4 mapped address is used to handle
inbound IPv4 traffic toward AF_INET6 sockets, and outbound IPv4 traffic
from AF_INET6 sockets.  Inbound case has higher probability of abuse,
while outbound case contributes to the abuse as well.  Here we briefly
describe the kernel behavior in inbound case.  When we have an AF_INET6
socket bound to IPv6 unspecified address (::), IPv4 traffic, as well as
IPv6 traffic, will be captured by the socket.  The kernel will present
the address of the IPv4 peer to the userland program by using IPv4
mapped address.  For example, if an IPv4 traffic from 10.1.1.1 is
captured by an AF_INET6 socket, the userland program will think that the
peer is at ::ffff:10.1.1.1.  The userland program can manipulate IPv4
mapped address just like it would do against normal IPv6 unicast
address.

We have three problems with the specification.  First, IPv4 mapped
address support complicates IPv4 access control mechanisms.  For
example, if you would like to reject accesses from IPv4 clients to a
certain transport layer service, it is not enough to reject accesses to
AF_INET socket.  You will need to check AF_INET6 socket for accesses
from IPv4 clients (seen as accesses from IPv4 mapped address) as well.

Secondly, malicious party may be able to use IPv6 packets with IPv4
mapped address, to bypass access control.  Consider the following
scenario:

o Attacker throws unencapsulated IPv6 packets, with ::ffff:127.0.0.1 as
  source address.

o The access control code in the server thinks that this is from
  localhost, and grants accesses.

Lastly, malicious party can make servers generate unexpected IPv4
traffic.  This can be accomplished by sending IPv6 packet with IPv4
mapped address as a source (similar to abuse of IPv4 compatible
address), or by presenting IPv4 mapped address to servers (like FTP
bounce attack [Allman, 1999] from IPv6 to IPv4).  The problem is
slightly different from the problems with IPv4 compatible addresses and
6to4 addresses, since it does not make use of tunnels.  It makes use of
certain behavior of userland applications.

The confusion came from the dual use of IPv4 mapped address, for node-
internal representation for remote IPv4 destination/source, and for real
IPv6 destination/source.

3.2.  Possible solutions

o In IPv6 addressing architecutre document [Hinden, 1998] , disallow the
  use of IPv4 mapped addresses on the wire.  The change will conflict
  with SIIT [Nordmark, 2000] , which is the only protocol which tries to
  use IPv4 mapped address on IPv6 native packet.  The dual use of IPv4
  mapped address (as a host-internal representation of IPv4
  destinations, and as a real IPv6 address) is the prime source of the
  problem.

o Reject IPv6 packets, if it has IPv4 mapped address in IPv6 header
  fields.  Note that we may need to check extension headers such as
  routing headers, as well.  IPv4 mapped address is internal
  representation in a node, so doing this will raise no conflicts with
  existing protocols.  We recommend to check the condition in IPv6 input
  packet processing, and transport layer processing (TCP input and UDP
  input) to be sure.

o Reject DNS replies, or other host name database replies, which contain
  IPv4 mapped address.  Again, IPv4 mapped address is internal
  represntation in a node and should never appear on external host name
  databases.

o Do not route inbound IPv4 traffic to AF_INET6 sockets.  When an
  application would like to accept IPv4 traffic, it should explicitly
  open AF_INET sockets.  You may want to run two applications instead,
  one for an AF_INET socket, and another for an AF_INET6 socket.  Or you
  may want to make the functionality optional, off by default, and let
  the userland applications explicitly enable it.  This greatly
  simplifies access control issues.  This approach conflicts with what
  IPv6 basic API document says, however, it should raise no problem with
  properly-written IPv6 applications.  It only affects server programs,
  ported by assuming the behavior of AF_INET6 listening socket against
  IPv4 traffic.

o When implementing TCP or UDP stack, explicitly record the wire packet
  format (IPv4 or IPv6) into connection table.  It is unwise to guess
  the wire packet format, by existence of IPv6 mapped address in the
  address pair.

o We should separately fix problems like FTP bounce attack.

o Applications should always check if the connection to AF_INET6 socket
  is from an IPv4 node (IPv4 mapped address), or IPv6 node.  It should
  then treat the connection as from IPv4 node (not from IPv6 node with
  special adderss), or reject the connection.  This is, however,
  dangerous to assume that every application implementers are aware of
  the issue.  The solution is not recommended (this is not a solution
  actually).
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jim Bound <[email-masked]>
Date: Fri, 21 Jul 2000 11:26:29 -0400

Itojun,

I am not commenting on IPv4 Mapped addresses on the wire.

What I do or don't do with them in userland is NONE of yours or anyone
elses business or what I do with them in my implementation.  The BASE
API and Addr Spec define them and they exist.

The only place they show up on the wire are in SIIT.

But I do want to see Bob's response to Jacks question which I am
concerned has not gotten a response yet?

I intend to read your input before the IETF and maybe we should talk
offline together as I think you have an implementation problem and I am
open to helping you fix this in the Kame code base if necessary or
explain it to you.

regards,
/jim

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Jul 2000 09:33:12 -0700 (PDT)

Itojun,

The implication of your recommendation is that we remove SIIT (at least
as currently specified) from the RFC directories, since the SIIT RFC
assumes that IPv4-mapped addresses can be sent in IPv6 headers and SIIT
can't work without this.

Is this really what you are proposing?

   Erik

---

From: Jim Bound <[email-masked]>
Date: Fri, 21 Jul 2000 13:05:30 -0400

Hi Erik,

>Is this really what you are proposing?

I hope not or I am against the proposal.

But I think we have to address Jack's question too.  Right now its
unclear whether SIIT is "legal" per the wording in the arch spec.

regards,
/jim
   Erik

---

From: Mauro Tortonesi <[email-masked]>
Date: Fri, 21 Jul 2000 18:31:25 +0200 (CEST)

>   ported by assuming the behavior of AF_INET6 listening socket against

i am not a software engineer - only a student and a developer - and
i am new of this list, so i don't even know if i am allowed to speak
here. but if you want to hear my opinion i think you shouldn't take such a
decision too easily. this would mean that nearly ALL ipv6 servers
and kernel implementations should be rewritten. that would a considerable
step back in the development of ipv6 software. imho there is also a 
contradiction with the development of draft-rfc2553bis towards a
protocol-indipendent api.

as mr. itoh says, the best solution is probably to forbid every use of
ipv4 mapped addresses except for node representation.

-- 
Aequam memento rebus in arduis servare mentem...

Mauro Tortonesi			[email-masked]
Ferrara Linux User Group	http://www.ferrara.linux.it
Project6 - IPv6 for Linux	http://project6.ferrara.linux.it

---

From: Jim Bound <[email-masked]>
Date: Fri, 21 Jul 2000 15:08:40 -0400

anyone can speak here and this is valuable.

the apis will work in 2553bis.  what one does with their implementation
and how they pass ipv4 or ipv6 to the app and the apis is not anyones
business in a standards community or anywhere else.  if one has an issue
with the API thats fine but not with how implementors build their stack.

a v4 packet in can become a mapped packet in an implementation.  when
presented to an af_inet.  Or it can be presented as an af_inet6 (as a
mapped address).  likewise going out.

rfc2553bis permit this behavior for the api and should and has for 5
years so thats a done deal and not really an IETF standard but an
informational rfc so the API for IPv6 is NOT AN IETF STANDARD. It will
standardized by the IEEE committees and XNET.

As far as v4 mapped on the wire for protocols thats a different
discussion.  I personally support that it is OK and support what SIIT
has done and ready for that discussion if someone does not believe it is
a good idea. 

but what I will react very badly too in my mail is any implementor that
cannot get something to work and that is what is driving their concern
and its not a standards issue for this forum, but this forum is being
used to change implementation folkways for IPv6.

but v4 mapped does not affect the ISV porting effort at all and in fact
makes their job much easier if the platform they are porting to supports
that paradigm.

do you have an example where you see the problem?

/jim

---

From: [email-masked]
Date: Sat, 22 Jul 2000 08:06:15 +0900

>API and Addr Spec define them and they exist.

	i too would like to see uniform API everywhere, possibly with
	enough simplicity to avoid applications writers misuse.  i have
	multiple routes to take with the issue i raised.

>open to helping you fix this in the Kame code base if necessary or

	thank you for the offer, but i don't think we have problem in our code.

itojun

---

From: [email-masked]
Date: Sat, 22 Jul 2000 08:09:51 +0900

>Is this really what you are proposing?

	as i wrote in the reply to Brian (Zill), i have multiple routes to
	pick from.  some of them is friendly with SIIT, however, if we take
	a route that is friendly SIIT, i think we leave too much complexity
	in the code/address arch, and we will see future security issues
	(complexity = possibility for security issue).

	i'm not sure if removal is necessary/required.  there are many RFCs
	that conflicts with each other, or RFCs requiring updates to old ones.

itojun

---

From: Mauro Tortonesi <[email-masked]>
Date: Sat, 22 Jul 2000 15:22:07 +0200 (CEST)

> makes their job much easier if the platform they are porting to supports

you are absolutely right. my concern was about api issues. a modification
in the behaviour of af_inet6 passive socket, so that they are not allowed
to accept connections from af_inet sockets, would have imho nightmarish
effects. 

there has been a misunderstanding. i wanted to say that forbidding the use
of ipv4 mapped address "on the wire" would surely eliminate all security
problems. as someone has pointed out, this is not acceptable - and i am
also of this opinion. but itojun is certainly right when he says that rfcs
and drafts should be precise, clear and not contradictory when dealing
with important matters that can become a security issue.

---

From: Jim Bound <[email-masked]>
Date: Mon, 24 Jul 2000 08:48:23 -0400

Mauro,

>to accept connections from af_inet sockets, would have imho nightmarish

An af_inet6 socket should not accept a connection for an af_inet socket.  
Any implementation specific code path in a hybrid stack (different from
a dual stack I think you know??) that does this or neglects the issue
will have problems as you state.  If an implementation does this it is
broken, the market will fix the correction.  Also we have never had this
problem at any test event.  Also early on I have run ftp, telnet, etc at
the same time and have not seen any bugs.  In fact what you ask is a
test at present.  

No where in any spec do we (the IETF or the XNET TBD API we are buildin
the base for here on ipng group) require how one uses mapped,
compatible, or native IPv6 addresses.  Nor should we other than to
define them and make them available to applications via the API.

>with important matters that can become a security issue.

If we could ever achieve perfection with any spec anywhere in the IETF
we would never ship a spec.  We go with what we can get done within in a
reasonable amount of time and test the implementations.  The market has
already started to port to IPv6 and ISPs are putting it in their RFPs as
other suppliers.

I see no change to rfc2553bis API for this dicussion. 

regards,
/jim

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Mon, 24 Jul 2000 15:51:28 -0500

The discussion below raises concerns with our proposed draft for
an SCTP sockets API.  SCTP is a reliable datagram transport developed
by SIGTRAN to carry telephony signaling information.

One distinctive feature of SCTP is direct support for multi-homed
hosts.  SCTP has the notion of a "primary address" to which it sends
most packets.  It may optionally send heartbeat messages to other
addresses of a correspondent node.  If the primary fails SCTP switches
to a different correspondent address.

The issue is that a single host may have both IPv4 AND IPv6
interfaces.  SCTP allows a single association (connection) to span
both kinds of interface.  In our API draft we have suggested af_inet6
as the socket type for associations with mixed address types.
Effectively, we can create a passive socket which listens for
connections on both af_inet and af_inet6 ports.

>An af_inet6 socket should not accept a connection for an af_inet socket.  

May I invite you to read draft-stewart-sctpsocket-sigtran-00.txt and
comment?  Have we missed a critical IPv6 consideration?
-- 
Put no trust in extortion,		La Monte Henry Piggy Yarroll
set no vain hope in plunder;		NIC Handle LY
if riches increase,
do not set your heart upon them.

---

From: "Randall R. Stewart" <[email-masked]>
Date: Mon, 24 Jul 2000 17:00:20 -0500

Dear All:

One note to all you readers.. this draft is a very very early
first cut. We rushed it out to get it in to the drafts editor
and thus it requires quite a bit of work yet :->

I did not get Jim's original email  so I have a hard time
reading the snippet below and making sense of it...

I can see a "Tcp compatible issue" in that it may be a bit
strange to listen on a "compatible" type socket and get
a connection to one that is only IPv4.. This may just be
a issue of NOT allowing it on the "TCP compatability type"
socket... The new interface I think should work fine ..I don't
see issues with it. I would be glad to note comments on these
and other items... as I said it is rough I am sure there are
all sorts of spelling and grammer problems yet to be fixed ..

Regards

R

-- 
Randall R. Stewart
[email-masked]

---

From: Jim Bound <[email-masked]>
Date: Mon, 24 Jul 2000 23:36:38 -0400

I think I may have been misunderstood.  Let me see if the response clears it
up?

>as the socket type for associations with mixed address types.

This is a good idea and why I believe a hybrid stack is far superior to
a pure dual stack implementation.  This paradigm is also inline with the
IPv6 deployment message which is IPv4/IPv6 Integration not Migration.
So I am real happy to hear SCTP is thinking that way too.

>connections on both af_inet and af_inet6 ports.

Yes.

>>An af_inet6 socket should not accept a connection for an af_inet socket.  

If there is a v4 listener and a v6 listener then that is fine.  the
af_inet connect in should go to the v4 listener and an af_inet6 connect
in should go to the v6 listener.  But it is perfectly valid for a v6
listener to accept connections from af_inet and af_inet6 incoming
connections, where af_inet will be mapped addresses. An ISV
server app can port to IPv6 supporting both v4 and v6, using af_inet6.

Above what I am saying is if a v4 listener and a v6 listener exist,
then af_inet incoming connections should be sent to the v4 listener.
Good catch I made to many assumptions about after the preposition "for"
and it was too terse.  But that is what I mean't by the prep phase
"for an af_inet socket".  Meaning let the v4 listner have that
connection, not the v6 listener.  Sorry.

There is an issue for the case where an app that is only doing v6
listener for both incoming af_inet and af_inet6, where the app may want
to not receive any connections from v4.  Bill Sommerfield pointed this
out to me offline.  The issue is that the v6 socket binds before a v4
bind and the v6 socket receives the v4 address as v4mapped.  What we
probably want to do is have a setsockopt in rfc2553bis that says DON"T
ACCEPT V4MAPPED connections (there are other ways to do this but the
socket level option is the cleanest).  But the idea is to not have
applications have to run two instances for v4 and v6, but only one
instance (e.g. telnet, ftp, NFS, sctp app, oracle app).  It also permits
ISVs to ship one code base and if the user does not even use IPv6 the
app still works, until the user turns on IPv6 ---> Integration.

This will come up at ipng meeting via Dave Thaler agenda item.  

>comment?  Have we missed a critical IPv6 consideration?

Its on my plate to read. I for one will try to respond to you privately and 
any other authors (as I am not on sigtran and trying to avoid that) before
next Monday a.m.  Do you want me to respond to the list if I see holes?
Your call?

thanks for listening,
/jim

---

From: Mauro Tortonesi <[email-masked]>
Date: Tue, 25 Jul 2000 17:46:13 +0200 (CEST)

> >to accept connections from af_inet sockets, would have imho nightmarish
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

sorry, my english is poor - let me explain better. suppose we have an ipv6
passive socket waiting for an incoming connection. it must be able to
recognise requests from ipv4 nodes and present them to the "accept" 
syscall as af_inet6 socket with an ipv4-mapped address.
imho this behaviour, which is specified in rfc2553, should not be modified.

> An af_inet6 socket should not accept a connection for an af_inet socket.  

you are right. they should open another af_inet socket and fall back to
an ipv4 connection. however, rfc2553 does not even suggest this behaviour.
quoting from draft-ietf-ipngwg-rfc2553bis-00.txt, section 3.7:

- Applications may use PF_INET6 sockets to open TCP connections to IPv4
- nodes, or send UDP packets to IPv4 nodes, by simply encoding the
- destination's IPv4 address as an IPv4-mapped IPv6 address, and passing
- that address, within a sockaddr_in6 structure, in the connect() or
- sendto() call.  When applications use PF_INET6 sockets to accept TCP
- connections from IPv4 nodes, or receive UDP packets from IPv4 nodes, the
- system returns the peer's address to the application in the accept(),
- recvfrom(), or getpeername() call using a sockaddr_in6 structure encoded
- this way. 
-
- Few applications will likely need to know which type of node they are
- interoperating with.  However, for those applications that do need to
- know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is
- provided.

let me understand, when an af_inet6 socket opens a connection with 
another af_inet6 socket with ipv4-mapped address, the communication
established is in ipv4, isn't it? so ipv4-mapped addresses are not only
used for node representation (as they are returned from getaddrinfo and
getipnodebyname), but also to establish a connection to an ipv4 host.

so the only protocol that requires ipv4-mapped addresses "on the wire"
is SIIT. if SIIT is not used, then the kernel can reject all connection
from outside with an ipv4-mapped address, for security issues - like
itojun has explained us very well.

by the way, can you point me to a rfc which explains the difference
between a hybrid stack and a dual stack? i have not read them all - maybe
i have missed an important one.

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Tue, 25 Jul 2000 11:38:48 -0500

>I think I may have been misunderstood.  Let me see if the response clears it
...
>[piggy wrote:]
>> both kinds of interface.  In our API draft we have suggested
>> af_inet6 as the socket type for associations with mixed address
>> types.
>
> This is a good idea and why I believe a hybrid stack is far superior
> to a pure dual stack implementation.  This paradigm is also inline
> with the IPv6 deployment message which is IPv4/IPv6 Integration not
> Migration.  So I am real happy to hear SCTP is thinking that way
> too.

Good.  I think I now understand your distinction between a hybrid
stack and a dual stack.

> If there is a v4 listener and a v6 listener then that is fine.  
...
> then af_inet incoming connections should be sent to the v4 listener.

Is this v4 listener listening on INADDR_ANY and the v6 listener
listening on in6addr_any for the same port?  IMHO this should be
illegal.  The second listener should get an EBUSY when attempting to
bind.

> socket level option is the cleanest).

Blech!  In SCTP we need to allow binding on arbitrary subsets of
addresses.  Our solution is to allow multiple calls to bind().  There
is nothing special about the sets "all IPv4 addresses" and "all IPv6
addresses" (well, there shouldn't be...).

> But the idea is to not have applications have to run two instances
> for v4 and v6, but only one instance (e.g. telnet, ftp, NFS, sctp
> app, oracle app).  It also permits ISVs to ship one code base and if
> the user does not even use IPv6 the app still works, until the user
> turns on IPv6 ---> Integration.

This is definately the way to go.  I shouldn't even have to "turn on
IPv6 Integration".  If all of my interfaces are ifconfig'd with v4
addresses, then I don't do IPv6...

> This will come up at ipng meeting via Dave Thaler agenda item.  

I'll make a point of attending, thanks.

---

From: Jim Bound <[email-masked]>
Date: Tue, 25 Jul 2000 13:49:25 -0400

Hi Mauro,

hey your bringing out important stuff here that needs to be understood.
thanks...it is just so busy before an ietf meeting on the lists...

>imho this behaviour, which is specified in rfc2553, should not be modified.

Great.  Your english is fine.  Mine has been bad here because I am so
busy I am typing in terse mode which I have stopped now, on this trhead
anyway.  Sorry.

>quoting from draft-ietf-ipngwg-rfc2553bis-00.txt, section 3.7:

OK I explained this in mail last night my "for" statement implied to much
for any reader.  Assume you have that mail?

>- sendto() call.  

>When applications use PF_INET6 sockets to accept TCP

>getipnodebyname), but also to establish a connection to an ipv4 host.

This is permissible but not required.  The API can ask for just plain
old IPv4 addresses too using af_inet with the API.  How thats
implemented in the stack is none of the standards groups business.

>itojun has explained us very well.

This should be permissable and I think we need to add a socket level
option for af_inet6 that states do not accept v4mapped connections, for
af_inet6 listeners.

This would be reflected in the next iteration (hopefully last call) 
in rfc2553bis. 

>i have missed an important one.

Hmmm.  There really is no rfc for this but you might want to do a search
on "hybrid stacks" on the web.  You can look at rfc1006, rfc1001/1002
which is very very old but is the key point of a hybrid stack.

Roughly let me try to explain without going off the deep end of
networking computer science derivations of how to build network stacks.

A dual stack typically means that each stack is fully implemented
completely for a networking protocol.  So for example using IP (can
apply to any network protocol) using BSD as a model.  There would be
ip_input4.c and ip_input6.c and tcp_userreq4.c and tcpuserreq6.c. I
don't think anyone has done anything like that I hope as that is pure
kernel bloat for the networking subsystem and to much duplication at
least for a product focused IP stack.

Another approach is to build a dual IP layer, common transport layer,
and a dual API layer, but the IPv6 API layer can handle both v4 and v6
(like DNS as an example).  This means that after the IP layer all IP
datastructures are 16bytes, hence, IPv4 is represented as v4mapped.
A hybrid stack integrates those parts of the stack where Ipv4 and Ipv6
can perform code reuse, avoid duplication of datastructures, but at the
same time avoid excessive conditional primitives within the stack
implementation.  For Ipv4 and IPv6 many of us were able to do this
(probably in different ways) and maintain the performance and
compatibility of IPv4 binaries.  To keep performance is a lot of work
but the integration of Ipv4 and IPv6 is worth the work from a "product
perspective".

What we have done in the IETF is use the term Dual Stack in most specs
to mean that an implementation can support both IPv4 and IPv6.  But most
of us have not built pure dual stacks but hybrid stacks.  If you look at
the basic transition mechanisms from Erik Nordmark and Bob Gilligan you
will see reference to "dual IP layer" draft-ietf-ngtrans-mech-06.txt
and I think far more appropriate than saying dual stack.  Even in one of
my co-author'd specs I am guilty of abusing dual stack 
draft-ietf-ngtrans-dstm-02.txt.  But we live with the misnomer in IPng.
It would be to much work and discussion to fix it.  But it always raises
its ugly head when we discuss the implementation of the APIs.

Also one of the advantages of IPv6 when it was first presented as an
IPng within the IETF was that we would be able to build a clean hybrid
IPv4+IPv6 stack, which in opinion would not have been possible with the
competing proposals back in 1993-1994 for IPng in the IETF.

You can also look at something we did disclosing our IPv6 Prototype
implementation details for a good discussion of what I allude to above,
but realize the paper is now old and whether we update it is TBD but it
is a good point of reference for you and open to the public to view.

http://www.digital.com/DTJN01/DTJN01HM.HTM

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Tue, 25 Jul 2000 14:00:35 -0400

>Good.  I think I now understand your distinction between a hybrid

Great.  See my last mail to Mauro too just sent I go into more detail on
the principle (or is that principal :----))

>illegal.  The second listener should get an EBUSY when attempting to

I think it should be illegal too.  Its like running telnetv4 and
telnetv6 on the same node.  Pretty stupid IMO.  But if we have a socket
level option to not accept v4mapped for af_inet6 it will let it happen
in theory (not that I believe we should).

>addresses" (well, there shouldn't be...).

I agree so an sctp app in this case would not set the socket level
option.

>addresses, then I don't do IPv6...

I agree.  Simple is beautiful to most users.

>I'll make a point of attending, thanks.

That would be good as your one of those **real** users of this API we
need to hear from.

/jim

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Tue, 25 Jul 2000 15:03:31 -0500

>the principle (or is that principal :----))

I didn't see it on either of the lists.  I'm still interested in your
definitions to see if I understand.

>in theory (not that I believe we should).

Forget the socket level option--just adopt the SCTP solution in
general.  If you are going to allow binding to subsets of addresses
you might as well make it completely general.

...
>>> listener for both incoming af_inet and af_inet6, where the app may
>>> want to not receive any connections from v4. [...] What we
>>> probably want to do is have a setsockopt in rfc2553bis that says
>>> DON"T ACCEPT V4MAPPED connections (there are other ways to do this
>>> but the socket level option is the cleanest).
>

There need not be anything SCTP-specific about calling bind() multiple
times...  You do not need the socket option at all.

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 25 Jul 2000 20:03:52 -0700 (PDT)

> addresses" (well, there shouldn't be...).

This is a point which is not clear in the current draft (in fact, there are
many things which are not clear as Randy said...).  The idea is that a v6
socket bind() to in6addr_any will associate the socket to all interface
addresses, regardless of whether they are v4 or v6.  A v4 socket bind() to
INADDR_ANY is only associated with v4 addresses.  There is no equivalent of v6
only bind() in the current draft (v6 socket trying to bind() to v4 INADDR_ANY
will fail). 

Whether we want to have a v6 address only bind() is an issue we need to talk
about.  There can be apps which support some v6 specific features and do not
want to be bothered with "accidental" v4 associations.  Instead of aborting
those associations when the apps accepts them, it may be better for the OS to
reject them right away.

							K. Poon.
							[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 25 Jul 2000 20:16:26 -0700 (PDT)

> you might as well make it completely general.

Allowing bind() to subsets of addresses does not necessarily mean that such
option is of no use.  A SCTP app may not want to find out all v6 addresses
in a machine (the way to find out is probably OS dependent) to bind() to.
And it just wants to deal with associations using only v6 addresses.  In the
current SCTP API draft, there is no way to do that.  Since we want code to
be OS independent, having such an option may not be a bad idea.

							K. Poon.
							[email-masked]

---

From: Jim Bound <[email-masked]>
Date: Tue, 25 Jul 2000 23:30:51 -0400

>you might as well make it completely general.

Well its not that easy.  We still do not want af_inet6 listner to get
the connections for IPv4 if there is an af_inet listener.  That is the
only real problem, which the socket level option fixes.
Whether we like it or not we will have to deal with stupid permisible
behavior like INADDR_ANY binding to port 23 and in6addr_any binding to
port 23.  It will happen.  

>times...  You do not need the socket option at all.

Thats not why we need it.
I need to still look at your sctp api so I can't comment on that.

/jim

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 26 Jul 2000 09:01:01 -0500

> only real problem, which the socket level option fixes.

To give a v4-specific listener priority over a v6 listener is not up
to the API but the stack's PCB lookup function, yes?  The only reason
I can see for a sockopt is to allow overriding this behavior -- but
the v6 application could do this more simply by binding to the v4
address (be it wildcard or not) in addition to any others.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Mauro Tortonesi <[email-masked]>
Date: Wed, 26 Jul 2000 16:25:22 +0200 (CEST)

> for any reader.  Assume you have that mail?

yes, certainly. 

> implemented in the stack is none of the standards groups business.

however, rfc2553 states that an application can use ipv4-mapped addresses
to open a TCP connection or send a UDP datagram to an ipv4 node. how can
this happen if the connection is not in ipv4? 

> This would be reflected in the next iteration (hopefully last call) 

imho such a sockopt is surely a good idea. 

> >between a hybrid stack and a dual stack? 
> Hmmm.

thank you very much for your answer.

---

From: Hideaki YOSHIFUJI (吉藤英明) <[email-masked]>
Date: Thu, 27 Jul 2000 00:11:20 +0900

> address (be it wildcard or not) in addition to any others.

We cannot do this with Linux.
-- 
Hideaki YOSHIFUJI @ USAGI Project  <[email-masked]>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Thu, 27 Jul 2000 00:40:15 +0900

>We cannot do this with Linux.

	the whole confusion of AF_INET and AF_INET6 interaction
	is documented very nicely in BIND9 doc/misc/ipv6.  the source of
	confusion is that we have no specification to look at - RFC2553
	should have documented how they should interact.  i think i have
	raised this more than a year ago on ipv6imp mailing list, and the
	comment was that this is implementation dependent thing.

itojun

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 26 Jul 2000 13:40:10 -0400

Looks like other people are running into trouble with the "accept ipv4
traffic through ipv6 sockets" feature:
    
http://www.isc.org/products/BIND/bind9.html, in the bind-9.0.0rc1
release notes:

    On some systems, IPv6 and IPv4 sockets interact in unexpected
    ways. For details, see doc/misc/ipv6. To reduce the impact of
    these problems, the server no longer listens for requests on IPv6
    addresses by default. If you need to accept DNS queries over IPv6,
    you must specify "listen-on-v6 { any; };" in the named.conf
    options statement.

					- Bill

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 26 Jul 2000 14:49:35 -0700 (PDT)

> address (be it wildcard or not) in addition to any others.

Another clarfication on the meaning of binding in the SCTP context.  The above
just talks about finding an endpoint to take an association request. In SCTP
an endpoint can have multiple addresses.  An SCTP endpoint can use any of
those addresses to communicate with a peer endpoint.  The binding to
in6addr_any means that when setting up an association, the system will
associate all its addresses to the endpoint.  This means that the peer can use
any (there is always a primary) of those addresses to communicate with it.  In
the current draft, all means both v4 and v6 addresses.  This may not be
desirable if the app uses some v6 features, e.g. routing header, which are not
applicable to v4 addresses.  This means that SCTP may not be able to use those
v4 addresses associated with the endpoint.  If this is the case, why should
those v4 addresses be associated with the endpoint in the first place?

Note that how the system picks those addresses are still not "clearly"
specified.  It may not make sense to pick all addresses associated with an
interface.  The reason for having multiple addresses is that SCTP can failover
to another address if the primary fails.  But if all the addresses are
associated with an interface, failover may not make sense at all.  There are
still a lot of work to be done in this area in the draft...

							K. Poon.
							[email-masked]

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Thu, 27 Jul 2000 16:28:48 -0500

>We cannot do this with Linux.

I have not gotten into the v6 portions of the networking code, but
what is the constraint?

---

From: Hideaki YOSHIFUJI (吉藤英明) <[email-masked]>
Date: Fri, 28 Jul 2000 08:55:51 +0900

> I have not gotten into the v6 portions of the networking code, but

Ipv6 tcp layer and ipv4 tcp layer are shared.
You cannot bind a ipv4 socket to a port already bound to ipv6 socket.
You cannot bind a ipv6 socket to a port already bound to ipv4 socket.

If you want to provide a service to ipv6 and ipv4 client through single 
local port, you must create an ipv6 scoket and bind to that port;
ipv4 clients are serviced by ipv6 scoket through ipv4-mapped addresses.

We may be able to  provide a new socket option that disables ipv4-mapped 
feature, but I wonder application might abuse; create ipv6 socket, set 
that sockopt and create ipv4 socket... then Linux cannot provide a service 
to ipv4 clinets. please note this...

-- 
Hideaki YOSHIFUJI <[email-masked]>

---

From: [email-masked]
Date: Fri, 28 Jul 2000 09:32:47 +0900

>ipv4 clients are serviced by ipv6 scoket through ipv4-mapped addresses.

	just a comment: the following items are completely separate.
	you can get any behavior you want, with any code structure.
	the first 3 line in the above does not match up.

	- whether tcp layer code is shared between ipv4/v6 or not
	- whether pcb layer code is shared between AF_INET/INET6 or not
	- whether you allow bind(2) to the same port, while counterpart is
	  already done that
	- whether you support RFC2553-inbound or not on AF_INET6 socket
	- whether you support RFC2553-outbound or not on AF_INET6 socket

itojun

---

From: Stig Ven�s <[email-masked]>
Date: Fri, 28 Jul 2000 11:32:39 +0200

> You cannot bind a ipv6 socket to a port already bound to ipv4 socket.

Unless you bind to specific addresses.

I find the Linux behavior pretty logical. Sometimes it gets in the way
though. An IPv6 socket option for not accepting IPv4 connections sounds
good, then one could bind both IPv4 and IPv6 sockets to the same port
without specifying addresses.

Stig
-- 
Stig Venaas
UNINETT

---

From: Hideaki YOSHIFUJI (吉藤英明) <[email-masked]>
Date: Fri, 28 Jul 2000 18:51:42 +0900

> Unless you bind to specific addresses.

Even if we bind to in6addr_any / INADDR_ANY.

---

From: Jim Bound <[email-masked]>
Date: Fri, 28 Jul 2000 11:07:30 -0400

hi Matt,

>address (be it wildcard or not) in addition to any others.

I see your point and agree on the behavior, but I don't want to\ mandate
implementation behavior either.

/jim

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Fri, 28 Jul 2000 11:27:23 -0500

>to ipv4 clinets. please note this...

This is actually the sematics which I advocate.  I assume I can still
bind separately to single addresses?

Our proposal for the SCTP is to allow you to bind to arbitrary subsets
of addresses.  The semantics of such an operation for SCTP are
slightly different for SCTP--each association on the transmission
endpoint will use ALL the addresses in the binding.  TCP semantics
call for connections coming in on ANY of the bound addresses.
-- 
Put no trust in extortion,		La Monte Henry Piggy Yarroll
set no vain hope in plunder;		NIC Handle LY
if riches increase,
do not set your heart upon them.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------