Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6"

From: Vladislav Yasevich <[email-masked]>
Date: Mon, 04 Feb 2002 11:48:43 -0500

Hello

I apologize for the very late mail as I finally found the time to go through
this spec,
but I have a few comments about Draft 4.

Section 11.2 [page 46]
>   ...
>   When the data size is larger than the MTU of the outgoing interface,
>   the packet will be discarded.  Applications can know the result by
>   enabling the IPV6_RECVPATHMTU option described below and receiving
>   the corresponding ancillary data items.

Since, in this case, we instantly know that the packet is dropped, wouldn't
it be better to specifically notify the application via a returned error code?
Particularly, in the case of traceroute that you mention in this section,
adding
error code would be a good indication because traceroute does not try to
receive
on it's sending socket.  This also applies to any other application that has a
sending and a receiving socket.  An error code would tell the application that
it should perform a receive operation to learn the mtu.

Section 11.3 [page 46]
>   ...
>   When the application is sending packets too big for the path MTU
>   recvmsg() will return zero (indicating no data) but there will be a
>   cmsghdr with cmsg_type set to IPV6_PATHMTU, and cmsg_len will
>   indicate that cmsg_data is sizeof(struct ip6_mtuinfo) bytes long.

What happens to any buffered data?  If there is buffered data that came before
the MTU error, should recvmsg() still return 0 and no data?

>   This cmsghdr will be passed to every socket that sets the
>   IPV6_RECVPATHMTU socket option, even if the socket is non-connected.
>   Note that this also means an application that sets the option may get
>   the ancillary data upon a too big message sent from other
>   applications to the same destination.

Actually, it's worse then that.  For non-connected sockets (I am assuming
non-connected
means no destination address specified), the ancillary data will be given to
all of them.
This now places a burden on the application to figure out whether they are
sending to a
given destination or not.  We ether need a warning here that the application
may
receive MTU ancillary data for a destination they do not care about, or we may
want to
restrict this to connected sockets only (i.e. the ones with destination
address set).

Section 11.4 [page 47]

>   This specification defines a get-only socket option to retrieve the
>   current path MTU value for the destination of a given connected
>   socket.
>   ...
>   This option can only be used for a connected socket, because a non-
>   connected socket does not have the information of the destination and
>   there is no way to pass the destination via getsockopt().  When
>   getsockopt() for this option is issued on a non-connected socket, the
>   call will fail.

Why limit this functionality to only a connected socket?  Is it because
of the odd semantics with providing data to a getsockopt?  I mean, the
application
could set the ip6m_addr to the destination address it wants to look up the MTU
for,
but it would be a little strange for an application to specify data on a
getsockopt().

Section 14.2 and 14.3 [pages 51 and 52]

It may be worth mentioning that AF_UNSPEC may also be used as an argument to
rcmd_af and rexec_af for protocol independent applications.  This aligns this
API closer to the basic api.

-vlad
++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tel: (603) 884-1079
Compaq Computer Corp.		Fax: (435) 514-6884
110 Spit Brook Rd ZK03-3/T07
Nashua, NH 03062
--------------------------------------------------------------------
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: Erik Nordmark <[email-masked]>
Date: Tue, 5 Feb 2002 10:23:24 +0100 (CET)

> it be better to specifically notify the application via a returned error

The X/Open (or whoever "owns" the socket standard now adays) socket
specifications allow for implementations where certain error
messages, such as EHOSTUNREACH etc, can not be returned as an
error to a send/sendto/sendmsg.

Implementations using asynchronous message passing between the socket layer
and the procol stack depend on this being allowable behavior.

So I don't think it would be useful to have the IPv6 socket API extensions
pretend that such implementations exist and indeed conform to the socket API
standards.

> What happens to any buffered data?  If there is buffered data that came
> before the MTU error, should recvmsg() still return 0 and no data?

The assumption is that the mtu indication is a separate "event"
("record" for those looking a *BSD socket code) thus in this case
the application would first receive the buffered data and then receive
the msg with no data and just msg_control.
 
> receive MTU ancillary data for a destination they do not care about, or we
> may want to

The purpose of the ancillary data item is to allow applications which do
not connect() their UDP sockets to correctly participate in path MTU
discovery.
So I think it makes sense to put in some explicit text saying that the
application needs to verify that it indeed has sent a packet to the 
desination.
However, in practise I don't see this being an issue. A UDP application
participating in path MTU discovery (i.e. any UDP application which wishes
to send packet larger than 1280 bytes) must maintain path mtu state for
all the peers it is sending data to. So receiving the IPV6_PATHMTU,
just means it need to find that state and update it.

> could set the ip6m_addr to the destination address it wants to look up the
> MTU for,

s/a little strange/completely inconsistent with getsockopt as defined/

One could envision being able to ask questions about destination addresses
where path MTU is one of the things to ask.
But this quickly evolves into being able to ask about other useful things
(cached rtt estimate, etc). I belive RTM_GET with routing sockets already
provides an API for asking all those questions.
Would it be useful to add a pointer to routing sockets in the spec?

> API closer to the basic api.

OK

  Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 05 Feb 2002 22:54:46 +0900

Thanks Vlad for the careful reading, and thanks Erik for the quick
response.

>>>>> On Tue, 5 Feb 2002 10:23:24 +0100 (CET), 
>>>>> Erik Nordmark <[email-masked]> said:

> and the procol stack depend on this being allowable behavior.

That's exactly the reason why the specification does not define an
error code in this case.  If necessary, I'll put some additional note
on this to Section 11.2, but it will still not specify a particular
error code.

> the msg with no data and just msg_control.

That's the same as my intention, and our implementation in fact acts
as above (i.e. the app first receives the buffered data).  The comment
is reasonable, so I'll clarify this explicitly.

> application needs to verify that it indeed has sent a packet to the 

OK.

> just means it need to find that state and update it.

I agree, and, please also note that IPV6_RECVPATHMTU is disabled by
default.  Thus, almost all applications would not receive the noisy
ancillary data.

> Would it be useful to add a pointer to routing sockets in the spec?

Hmm, it's okay with me, but, we may even have to remove the section
and just mention the possibility of the more generic mechanism.  Do we
really have to need the specific interface (i.e. IPV6_PATHMTU)?

(If there's no strong opinion, my default take will be to keep the
current spec with some note on the general interface.)

> OK

Okay with me, too.  Actually, our implementation of rcmd_af() has
already supported the case of AF_UNSPEC.

I'll soon revise the draft with taking all into account.  If anyone of
you has further comments, please make them here.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Tue, 12 Feb 2002 14:15:14 +0100

Some late comments about draft-ietf-ipngwg-rfc2292bis-04.txt:
 - 0: is it time to alias sin6_scope_id to sin6_zone_id (far better name
   but not suitable for the basic API)?
 - 2.1.1: IPPROTO_IPCOMP (108, RFC 3173) is missing (as usual :-).
 - 2.2.2: ND_RA_FLAG_HA (for Mobile IPv6) is missing
   (note: only some Mobile IPv6 features are enough stable to be added
    today in the advanced API, another way is to mandate the definitions
    for the API in Mobile IPv6 (and other) documents)
 - 2.2.2: draft-ietf-ipngwg-icmp-name-lookups-08.txt ???
   (same issue but the document should be published soon and
    it is too late to add definitions)
 - 2.4: IPComp again...
 - 6.1: IPV6_PKTINFO/IPV6_MULTICAST_IF precedence is defined but
   there is nothing about sin6_scope_id (IMHO the behavior should be:
   raise an error if the interface is not in the zone, i.e. interface
   specification is a more accurate specification).
   6.2 tries to explain but is not enough clear/formal about this point
   and misses the fact that the issue can be for both sin6_scope_id of
   the source (bind()) and destination (connect/send*()) socket addresses.
 - 6.2: why IPV6_PKTINFO is not simply forbidden for TCP (i.e. raise
   an error in place of ignore)?
 + 6.3: good explanation of IPV6_HOPLIMIT vs. basic API stuff!
 - 6.5: are some definitions of well known values useful?
   (IMHO this is the job of DiffServ WG to answer)
 - 9.2: this text should make clear the assumption of RFC 2460 recommended
   ordering is abusive. I propose to remove IPV6_RTHDRDSTOPTS which
   has no current use too, so we can get the same kind of text than
   for routing headers (known limitations, possibility for clever kernels
   (i.e. a kernel which knows that a tunnel encapsulation limit must be
    before the fragmentation header when a packet with a TEL is fragmented)).
 - 11.2: I share Vladislav's concerns (the MTU stuff is a bit too complex)
 - 11.4: there is a discussion about MTUs and extra headers added by
   the kernel (Mobile IPv6 options). IMHO the MTU is an IP MTU so should
   not take into account the headers. But this makes it less useful
   for the programmer... (note: this is just a philosophical question
   for the 2292ter)
 - 11.5: is IPV6_REACHCONF really useful (example)?
 - 12: see 9.2

Regards

[email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 13 Feb 2002 03:02:30 +0900

>>>>> On Tue, 12 Feb 2002 14:15:14 +0100, 
>>>>> Francis Dupont <[email-masked]> said:

> Some late comments about draft-ietf-ipngwg-rfc2292bis-04.txt:

Thanks for the detailed comments.  (But, yeah, this is a bit late.  I
just submitted the 05 version...)

>    but not suitable for the basic API)?

I'm tempted to incorporate this into this API spec as a co-author of
the scoping architecture draft, but I don't think the advanced API is
the proper place to define the alias.  sockaddr_in6 is definitely a
product of the basic API, so if we decided to define the alias
somewhere, the place should be "a kind of" basic API document.  Just
because the basic API spec is in the last stage of standardization
cannot be the reason to define a new stuff in the advanced API.  I
hope you accept this position.

>  - 2.1.1: IPPROTO_IPCOMP (108, RFC 3173) is missing (as usual :-).

Since this is not specific to IPv6, I don't think we'll have to
incorporate this definition to this API spec (I admit IPPROTO_ESP and
IPPROTO_AH are not specific to IPv6 either, but they are at least
mandatory stuffs in IPv6 and are mentioned in RFC 2460).  As I said
the other day, we cannot just incorporate all the miscellaneous
definitions to the advanced API spec...

>     it is too late to add definitions)

One of the main decisions in recent revisions of this draft is that we
should stick to already-standardized definitions, that is, definitions
that are in an RFC status.  We did not want to depend on moving targets.
I tend to agree with the icmp-name-lookup stuff, but I believe we can
live without the definitions, at least in this particular API document.

>    the source (bind()) and destination (connect/send*()) socket addresses.

Section 6.7 describes how the outgoing interface is chosen.  The items
1 to 5 in this section do not depend on the sin6_scope_id value of the
source (specified by bind(2)) and destination (specified by connect(2)
etc) addresses.  And then the text says that the implementation should
check the scope zone boundary wrt the outgoing interface and the scope
zone of the source/destination addresses.

Isn't this enough?  If not, could you be a bit more specific on how
the text should be?

>    an error in place of ignore)?

Hmm, since there probably exists no TCP application that tries to set
IPV6_PKTINFO for specifying the source address, it would be clearer to
forbid this case.

>    (IMHO this is the job of DiffServ WG to answer)

I'm not sure about this comment.  What exactly do you want in this
section?  Are you requiring some revise in this section?

>     before the fragmentation header when a packet with a TEL is fragmented)).

Please let me make sure about this comment...are you proposing to
remove IPV6_RTHDRDSTOPTS and to let the kernel choose a proper
position of a destination options header (only with the IPV6_DSTOPTS
option)?  If so, how can a user specify a couple of destination
options headers before and after a routing header?

As for the recommended header ordering in RFC 2460, I don't mind to
make more comments that we cannot always assume the recommended
ordering (actually I tried to explain this fact throughout this
document.  the ordering is just a limitation in this particular API.).

>  - 11.2: I share Vladislav's concerns (the MTU stuff is a bit too complex)

Do you mean the send() message should return an (immediate) error when
the packet is not fit in the outgoing link MTU?  But, as Erik
explained in his reply to Vlad, we cannot always expect the immediate
error.  I admit the spec is a bit complex, but the spec should be
generic enough (i.e. we cannot assume a particular type of OSes.)

>    for the programmer... (note: this is just a philosophical question

I understand your concern, but, anyway, the value returned by
IPV6_PATHMTU is just a hint of the initial MTU.  Even if it is too
big, the application can then adjust the packet size with succeeding
MTU notification (assuming that it also specifies IPV6_RECVPATHMTU).

So, I'd propose to clarify that the MTU is an "IP MTU" (in your
definition above) and can be larger than the actual current path MTU
when the kernel inserts additional headers.  Is it okay with you?

>  - 11.5: is IPV6_REACHCONF really useful (example)?

Honestly, I personally do not see a practical usage of this option.
At least I've never seen an application that uses it.  I don't mind to
remove this, but if any other person wants to keep it, I'll just leave
the current text as is.  The definition has been there since a quite
old revision of the draft, and it can at least be implemented.

>  - 12: see 9.2

(again) I'm not 100% sure about the point.  Do you propose to remove
IPV6_RTHDRDSTOPTS from this section, too?  (If we can reach consensus
in 9.2, I'll of course revise this section accordingly.)

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Feb 2002 20:16:10 +0100

=> sorry...

   >    but not suitable for the basic API)?
   
   Just because the basic API spec is in the last stage of standardization
   cannot be the reason to define a new stuff in the advanced API.

=> will be for the next version of the basic API...

   >  - 2.2.2: ND_RA_FLAG_HA (for Mobile IPv6) is missing
   
   One of the main decisions in recent revisions of this draft is...

=> so we have to require the definitions somewhere (a rfc2292ter I-D?)
   
   >  - 6.1: IPV6_PKTINFO/IPV6_MULTICAST_IF precedence is defined...
   
   Section 6.7 describes how the outgoing interface is chosen.

=> I've missed this forward reference!

   
=> examples of a well known value are code points of class selectors
(but they are not IPv6 specific).

   option)?

=> yes

   If so, how can a user specify a couple of destination
   options headers before and after a routing header?
   
=> he cannot but he doesn't need it and he cannot specify
a destination option header just before a fragmentation header.
IPV6_RTHDRDSTOPTS is unnecessary and misleading.

   
=> I've read Erik's answer but just try to explain the MTU stuff to
a common programmer...

   
   
=> there is already a document about this so I don't believe you need
to modify the 05 draft. This is more a remark for the other document
(BTW I've found a candidate for the previous point :-).

   
=> I don't believe the "it can at least be implemented" argument is
enough to keep something (the opposite is :-).

   
=> yes, please remove IPV6_RTHDRDSTOPTS from everywhere.

Thanks

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 12 Feb 2002 14:50:58 -0500

Francis

...
> => yes, please remove IPV6_RTHDRDSTOPTS from everywhere.

Why do you belive the IPV6_RTHDRDSTOPTS is unnecessary?
Is it because of the lack of options that would go into this header?
Or is it because of the restrictive ordering (i.e 2460 recomended ordering)?

-vlad

P.S.
From what I remember of the discussion about header ordering constraints was
to stabilize this API and then figure something out that would not be
restrictive.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Feb 2002 22:01:50 +0100

=> this is the main reason. In fact the only destination option
in the draft (or in a RFC), the tunnel encapsulation limit,
needs to be in a place not in the recommended ordering.

=> we know this ordering is bad so there is no reason to insist
to enforce it. IPV6_DSTOPTS is enough.

   P.S.
   
=> we can't do all what we want so the minimum API is the best. One day
we'll try to fix this with a more powerful API but KISS + clever kernel
is the best for today.

Regards

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Feb 2002 14:56:52 +0100 (CET)

> when the kernel inserts additional headers.  Is it okay with you?

I think the philosophical question is deeper.
Knowing the size of IP packets that can be sent without IP fragmentation
(the path mtu) isn't that useful to an application when IP might add a
variable amount of headers to the packet and the transport might in
theory do the same.

What would be useful to the application is something
like "MAX_UNFRAGMENTED_SEND_SIZE"
i.e. the largest amount of data that can be passed to send/sendto 
without causing IP fragmentation.

Today with UDP over IPv6 the difference between this and path MTU is
just a constant.
But with mobile IP the sending IP stack some times inserts home address options
and/or routing headers in which case the difference isn't constant.

Of course, applications using sendmsg with ancillary data have more problems
in this area since they need to know what size headers result from
the ancillary data items they pass down e.g. that IPV6_HOPLIMIT
doesn't add headers but IPV6_DSTOPTS does add.

> old revision of the draft, and it can at least be implemented.

An application like a DNS resolver library might pass this down
on a sendmsg when it has recently gotten a reply from the same server.
But the saving of the NUD probe in this case isn't yet a strong enough 
motivation to pass down IPV6_REACHCONF. It's hard to tell whether this
motivation will be stronger in the future.

   Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 14 Feb 2002 02:55:59 +0900

>>>>> On Tue, 12 Feb 2002 20:16:10 +0100, 

> => so we have to require the definitions somewhere (a rfc2292ter I-D?)

Probably yes.  (Particularly) as for mobile IPv6, it will need quite a
lot of new API stuff and I think it is worth a separate draft.

> => I've missed this forward reference!

Okay, then I'll just add a reference to Section 6.7 in 6.1.

   
> (but they are not IPv6 specific).

Right, so I'll just keep the current text without mentioning
particular traffic class values.
(but I'll contact itojun, who is the author of the original
draft of this Section, if I miss something here.)

   
> IPV6_RTHDRDSTOPTS is unnecessary and misleading.

Hmm, I admit that the single IPV6_DSTOPTS would be enough for today's
(even "advanced") applications.  So I, for one, can live with the
single option.  However, I'm also quite sure this part is
controversial.  I'd like to know others opinions...

   
> => I've read Erik's answer but just try to explain the MTU stuff to

So, what do you want in this section?  Are you requiring a change
here?  If so, please be more specific.

   
   
> to modify the 05 draft. This is more a remark for the other document

Okay, thanks.

   
   
> enough to keep something (the opposite is :-).

Fair enough.  Again, I don't mind to drop this section unless someone
wants to keep it.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 14 Feb 2002 03:09:01 +0900

>>>>> On Wed, 13 Feb 2002 14:56:52 +0100 (CET), 

>> >  - 11.4: there is a discussion about MTUs and extra headers added by

(snip)

> doesn't add headers but IPV6_DSTOPTS does add.

(As a "philosophical" argument) I agree with all the points.  But as
for the API document, we should (or can) just keep the current text,
as Francis agreed in his message.

> motivation will be stronger in the future.

Agreed, so, are you okay with removing this section?

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Wed, 13 Feb 2002 19:28:27 +0100

=> this was my motivation... An application can discover (with the
DONTFLAG) the MTU is useless but this (DONTFRAG) doesn't provide
an easy way to get the information. In fact only TCP has a TCP_MAXSEG
which returns the MSS but TCP takes care of this too and headers
can be different per protocol/port/etc.

I believe to get the advanced API published is more important.

Regards

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 13 Feb 2002 14:15:41 -0500

> controversial.  I'd like to know others opinions...

Well, for one, I don't see a good enough reason to remove this.  This
particular interface allows the user to specify the header that is discribed
in 2460.  Remembering how much discussion (trouble) we all had figuring out
this DO Header stuff, I would leave this particular option there.  This
way, anyone trying to use 2460 header ordering can do so.

> here?  If so, please be more specific.

Would you agree on adding the text similar to Section 6.6 about an additional
error message on sendmsg().  The precendence is already set by Section 6.6,
but I don't have a very strong opinion on this.

> Fair enough.  Again, I don't mind to drop this section unless someone

No strong opinions about this.  For most short communications (e.g. UDP)
it may not be very usefull (particularly in view of DELAY_FIRST_PROBE_TIME
being 5 seconds, so NUD waits a while).  For long communications,
it probably will not be usefull either.

-vlad

---

From: Francis Dupont <[email-masked]>
Date: Wed, 13 Feb 2002 21:02:27 +0100

=> I expect less objections to simplify things than for the opposite...

      

=> If there is no proposal for a simpler version, keep it... and
be ready to explain it if someone is getting the strange idea to use it (:-).

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Wed, 13 Feb 2002 21:05:39 +0100

=> please keep the current text, we'll see for something else/better
for the next revision (the advanced API doesn't need to be perfect,
it needs to be published!)
   
Thanks

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 24 Jan 2002 11:20:46 +0900

>>>>> On Wed, 23 Jan 2002 10:40:49 -0800, 
>>>>> Bob Hinden <[email-masked]> said:

> This is a IPv6 working group last call for comments on advancing the 
> following document as an Informational RFC:

Thanks for the announcement.  Here is a tiny (and perhaps trivial)
correction:

> This document will replace RFC2592 that is an Informational RFC.  The 
> changes from RFC2592 are listed in section 17 of the internet draft.

These "RFC2592" should be "RFC2292", of course.

					JINMEI, Tatuya

---

From: Bob Hinden <[email-masked]>
Date: Wed, 23 Jan 2002 10:40:49 -0800

Title		: Advanced Sockets API for IPv6
	Author(s)	: R. Stevens, M. Thomas, E. Nordmark, T. Jinmei
	Filename	: draft-ietf-ipngwg-rfc2292bis-04.txt
	Pages		: 79
	Date		: 15-Jan-02

Please send substantive comments to the ipng mailing list, and minor
editorial comments to the authors.  This last call period will end two
weeks from today on February 6, 2002.

Bob Hinden / Steve Deering

---

From: Bob Hinden <[email-masked]>
Date: Thu, 24 Jan 2002 16:50:56 -0800

Thanks for the correction.  My error in the announcement.

Bob

At 06:20 PM 1/23/2002, JINMEI Tatuya /

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Feb 2002 19:04:17 +0100 (CET)

> it needs to be published!)

Agreed.

  Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 20 Feb 2002 23:48:13 +0900

>>>>> On Wed, 13 Feb 2002 14:15:41 -0500, 
>>>>> Vladislav Yasevich <[email-masked]> said:

> but I don't have a very strong opinion on this.

Okay, I'll add EMSGSIZE as an additional error to Section 11.2.

					JINMEI, Tatuya