Dave,
All your comments have been addressed. It may be some edits got missed and
I will take blame for that, as I was moving files between different systems
of late but things are stable now.
> Since some of my comments to the authors on 1/25
> are substantive, and none have yet been addressed,
> I'm resending to the ipng mailing list as requested.
> Point #6 is controversial, and arguments for both sides have each
> been presented by multiple proponents on the apifolks list.
Yes and has been discussed and we took what we believe to be consensus from
that
mail and your free to continue to object, but we hoped you would not.
>
> 1) Section 3.5 talks about creating an "IPv6/UDP" socket
> with a socket call with PF_INET6. Later, in section 3.7, the
> reader finds out that it isn't an "IPv6/UDP" socket at all,
> but a sort of hybrid IPv6+IPv4/UDP socket. To create
> a pure "IPv6/UDP" socket, one needs to also use the setsockopt
> described in 5.3. It would be nice if the discussing in 3.5
> wasn't so misleading. For example, how about adding a
> parenthentical forward reference like:
>
> OLD:
> > Applications may create IPv6/TCP and IPv6/UDP sockets by
> simply using
> NEW:
> > Applications may create IPv6/TCP and IPv6/UDP sockets (which may
> > also handle IPv4 communication as described in section 3.7)
> by simply
> > using ...
I am fine with this but 3.7 has been in the spec for 6 years. I will attach
a very
good note from one api implementor which will apply to your point #6 too. I
also do not recall your input on this on apifolks? This is not a problem to
fix.
>
> 2) Section 5.2's first sentence seems to limit applicability to UDP.
> Neither this document, nor 2292bis mentions that these can be used
> with RAW sockets (or conceivably non-UDP dgram sockets if anyone
> defines one). This needs to be fixed in one place or the other.
> My own preference would be for this section to just say
> these options
> will fail on SOCK_STREAM sockets, and leave it at that.
This is what I consider inherent for a base Info api, but we can do this as
the
IEEE will want this fixed too. OK fine. Again first time I have seen this
one.
>
> 3) The description of IPV6_MULTICAST_IF should say (as is done for
> IPV6_JOIN_GROUP) what happens if the app specifies 0.
> (I believe this should tell the kernel to choose one.)
This the implied behavior but we can add if the app specifies zero the
implementation
must select the interface. Not magic just smart code :----)
>
> 4) IPV6_LEAVE_GROUP is similarly terse. If the app passes 0 as the
> interface to IPV6_JOIN_GROUP, the current wording implies that
> it has to magically figure out which interface the kernel chose
> and specify that interface in the leave. The wording should
> be updated to say that the value of the interface field
> should match
> whatever the app used in that field in its IPV6_JOIN_GROUP call.
We can fix the wording but what you say is what I did anyway when I wrote
the
code for this. OK fine.
>
> 5) Section 5.3's title uses "IPV6_ONLY" whereas the socket option
> is IPV6_V6ONLY. These should be consistent, or else the title
> shouldn't contain something that looks like a defined constant.
This is a bug yes it should have been fixed.
>
> 6) Section 5.3 states that the ipv6-only option is off by default.
> Like the discussion of bind semantics where we agreed to disagree,
> I strongly object to this as a requirement, for somewhat analogous
> reasons. Some stacks today (ours being one of them) are such that
> the behavior is "on". Changing the default will break apps.
> As with bind semantics, IMHO it's better to put the burden
> of always
> setting the option, on apps that need to be portable across OS's,
> rather than apps that are written for a single OS (whether it
> be Solaris 8, Windows, Linux, or anything else). The only reason
> this is a problem is that both stacks and apps already exist that
> people depend on the behavior being "on" by default, and I believe
> it's too late to force everyone to change. Sad but true.
We cannot get consensus here. But your implementation was one of the last
ones done. All implementations but yours has no problem with the default
on.
On apifolks one other wanted to change it but most did not. We should not
alter
the behavior of this default for your implementation it would say your
implementation
is more important than others and that is not true at all. Also see the
attached
mail from one api implementor from apifolks.
So the default will stand as is as far as I am concerned and consensus in
this working group. If you want to begin this discussion here again then
you will go
against the apifolks list consensus. Thats fine do so. But see the
attached mail and the working group should read it too.
>
> 7) In section 6.2, a strange character is present where an
> apostrophe should be, in two places:
> > name will not be returned. If the node^?s name cannot be
> located, the
> ^^ here
> > host^?s name cannot be located.
> ^^ here
Hmmmm. Will fix this I don't have it on my nroff output.
>
> 8) In section 6.4:
> > [...] Note that IN6_IS_ADDR_LINKLOCAL
> > and IN6_IS_ADDR_SITELOCAL return true only for the two
> local-use IPv6
> > unicast addresses. [...]
>
> I believe "types of" should be inserted after "two".
> There's certainly more than two local-use unicast addresses...
> Furthermore, it would help to illustrate the point by explicitly
> stating what the result of the test
> IN6_IS_ADDR_LINKLOCAL( ::1 )
> is, especially in light of the fact that the scoped-arch document
> says ::1 is link-scoped (i.e. it should return false, and it's
> worth noting this, similar to the current note about multicast
> addresses).
Fine with "types". We should not add explicit tests to this spec.
What do others think? I suggest we let IEEE add specific tests.
thanks for the careful reading.
attached for all is from Jack McCann at Compaq on point #6 and sums up my
view of this and I believe most of our design team and implementors view:
---------------------------------------
I'm in favor of having the default behavior specified. It would be
rather pathetic to place the burden of our inability to agree on
a generation (or more) of application developers.
Further, I'll point out (again) that the default behavior is already
specified, and has been since draft-ietf-ipngwg-bsd-api-01.txt (1995),
the precursor to rfc2133, rfc2553, and 2553bis. That default
behavior is to allow AF_INET6 sockets to operate over IPv4. The
wording, essentially unchanged since 1995, is:
"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."
(Note this section would need to be modified if we change the default
to V6ONLY == 1.)
The V6ONLY option was introduced to provide a way for a program
to alter that default behavior.
We may also want to consider this in the context of the two
programming models:
1. single AF_INET6 socket handles both IPv4 and IPv6 -> wants V6ONLY == 0
2. separate AF_INET and AF_INET6 sockets for IPv4 and IPv6 -> wants V6ONLY
== 1
Speaking generally, the single-socket model provides a simple port
for existing single-socket applications. The separate-socket model
provides protocol independence, but at the cost of additional code
changes for existing single-socket applications. One could argue
that since we're already paying the additional code cost in the
separate-socket model, that's where we should add code to set
V6ONLY to 1, and not increase the code changes required in the
simpler single-socket model.
As for the argument about some existing implementations defaulting
to V6ONLY == 0, and others defaulting to V6ONLY == 1, one could
argue that a V6ONLY == 1 implementation is not conformant to
any existing version of the six year old API specification (see
bsd-api-01 comments above). Vendors are now shipping conformant
commercial products, this is not the time to change a behavior
that has been stable and specified for 6 years with multiple
conforming implementations.
As for the argument about IPv4-mapped addresses bypassing access
controls, one could argue that is simply a porting bug.
- Jack
-----------------------------------------------
thanks again,
/jim
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
