Hello,
As an IPv6 stack/application programmer, I'd really like to fix the
advanced API. The current situation is really mess, because
rfc2292bis does not provide backward compatibility to the old RFC
2292, and some OSes has already shipped with rfc2292bis while some
other OSes still keep RFC 2292. I believe we should basically go with
rfc2292bis, since it has fixed many issues (bugs, in fact) in the old
RFC spec, and some of them are essential for some applications
(e.g. the IPV6_USE_MIN_MTU option for DNS servers).
The most difficult issue would be the one for extension headers.
According to a recent discussion about MIP6 issues, the API should be
flexible enough to send/receive extension headers in any order, whereas
rfc2292bis basically assumes the recommended order of the headers
specified in RFC2460. Since it could be a fundamental change of the
API spec, I'm not sure if we can get a consensus so smoothly.
Anyways, I'll raise this issue later in a separate thread.
Apart from the extension header issue, I'd like to start with the TODO
and open issues list in draft-ietf-ipngwg-rfc2292bis-02.txt (which has
already expired, but you can still get it at
ftp://ftp.kame.net/pub/internet-drafts/) with some comments. If
you're intested in this topic, please review them and tell me your
opinions.
If possible, I'd like to see the next revision of the draft before the
next IETF meeting in London. So my question is:
does anyone (especially in the authors) try to revise the draft now?
If not, and if no one have time to do it for the moment, I'll be a
volunteer to edit the text for the next revision. Please let me know
your opinions.
Thanks,
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
from TODO/Open list in the previous version of the draft:
18. TODO and Open Issues
Items left to do:
- Add macros for ip6_hdr to access the traffic class and flow label
fields.
I don't recall the discussion (if any), but I think it's just a naming
issue.
- Should we remove the 1, 2, 4, 8 byte restriction for
inet6_opt_set_val and inet6_opt_get_val? Option values can be
any size even though there alignment must be a power of two.
Yes, I think so. And,
Issue of how natural alignment is defined for sizes that are not
a power of two.
this can be left as implementors' choice, IMO.
- Perhaps we should add a note to point out that robust receivers
should verify alignment before calling inet6_opt_get_val(). Or
require that inet6_opt_get_val() should check the alignment and
fail by returning -1?
I believe the draft just note possible unaligned data, and the library
implementation itself should be careful about the alignment issue.
- Should we change IPV6_USE_MIN_MTU to IPV6_USEMTU taking a
uint32_t Should we add IPV6_DONTFRAG option for traceroute??
Through a former discussion, we should just go with the
IPV6_USE_MIN_MTU. I'm still not sure about the IPV6_DONTFRAG option.
- Add credits for UDP MTU stuff
- Move information about mapping from inet6_opt to setsockopt and
cmsg.
What exactly do these two items mean?
- Clarify IPV6_RTHDRDSTOPTS's interaction with IPV6_RTHDR.
This would be the most difficult issue. We'll discuss it separately
later.
- Make the new inet6_opt_set_val() and inet6_opt_get_val() check
the length of the data item.
It would be just an editorial issue.
- Add sending and receiving sections for routing header text just
like destination options?
This should be a part of difficult issue.
- Include sample implementation of inet6_opt_XXX.
We (KAME) can contribute our implementation as sample code.
- Fix Authors address wrt Rich.
It's an editorial issue. (But what is the best "address" for him?)
Open issues:
- Add ICMP name lookups definitions?
Since the standardization has not proceeded, I think we should fix the
API without the definition.
- Add site-prefixes definitions?
Ditto.
- Add flow label allocation API as requested in draft-berson-rsvp-
ipv6-fl-00.txt? Draft has expired!
We now have a separate draft on this issue
(draft-itojun-ipv6-flowlabel-api-01.txt). As described in the draft,
I think we should fix the advanced API without this "more-advanced"
stuff.
- Anything special for mobility options? Restrict setting at API?
Filter out on receipt? If received what does the home address
option contain?
IMO, we should fix the API without the restriction and filtering. As
for reception of the address, I recall some discussion on this.
Someone proposed that the remote address (such as the one returned by
recvfrom(2)) should be the home address, and that the care-of address
should be in the corresponding home-address option when some
RECVDSTOPTS variants are specified. However, I'd rather leave the
destination address option as is, and introduce a separate RECVxxx
option if we really need to pass the option to the application.
- Specify "change" for TCP especially when there are multiple HBH
option headers etc.
??? what does "multiple HBH option headers" mean? The IPv6 spec
requirs a HBH option header appear only once in a single packet. Is
this a typo, and should this be "multiple DST option headers"?
In any case, sending/receving extension headers is the most difficult
part. We'll discuss this later.
- Specify binding to scope-id => implies filtering of addresses
with that scope if the address you are bound to is link-local
etc. What about conflicts with bound scope-id and sendto/connect
scope-id?
- Specify order for ifindex selection. Put in separate section.
Different cases for sending to link-local (scope_id including
nexthop scope_id) and global. Is multicast different?
- bind() and sin6_scope_id. Should have been in Basic API. Error
checks when bind/sendto sin6_scope_id does not match?
These three would depend on the result of the discussion about the
semantics of the sin6_scope_id field (i.e. flat 32 vs 4+28 split).
We'll think about this issue once the semantics is fixed.
- Specify notion of default multicast interface? In Basic API?
I don't think we should note it in the advanced API, but do not oppose
if someone really wants this.
- What about site names and site ids? Need for interfaces to map?
Requires that site-prefixes pass name - does name need to use DNS
format to handle character sets?
I believe we should fix the API without this stuff, since this is a
highly advanced issue.
- If the home address option passed out in IPV6_RECVDSTOPTS? If so
what address value does it contain?
As I said above, I'd prefer a separate option if we really need to
pass the home address to applications.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
