Date: Wed, 27 Jun 2001 22:27:07 +0900
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| >> - Fix Authors address wrt Rich.
| I don't know a common sense in such a case, either. rfc2553bis has
| the same issue, and the latest draft simply removed his address.
I'd wait and see how much of the doc ends up changing. If it is
comparatively little, leave him as an author for the next rfc version
then move him to acks for the one after that (if there ever is another).
If there are lots of changes, do it now. If he stays as an author, in
the authors' address section, just list him as "W.Richard Stevens (deceased)"
| > Is there really something in RFC 2460 which says that packets with
| > multiple HBH headers should be dropped?
|
| I believe the last sentence of the following paragraph in RFC2460
| specifies the behavior:
Yes, looks right - certainly it is the sane way to define things.
| > 2.1.2. IPv6 Extension Headers
| >
| > I think it would be useful to define a generic structure to specify
| > IPv6 extension headers, since we sometimes encounter a situation where
| > we can't detect the type of an extension header but should deal with
| > the header.
Huh? If you can't detect the type of the header, you can't do anything
with it at all, you certainly can't find its length, or what the next
header type will be (there's certainly no expectation that all future
headers will necessarily follow the most common layout of those fields,
and without that you're sunk). Unknown headers are "drop the packet"
and always have been (as in the paragraph you quoted).
| I will add that unless somebody disagrees.
So, count one disagreement. In any case a u_char for the length is
not necessarily going to be enough.
| But I might hold off for a while on icmp name lookups and site prefixes
| so we can see what will happen with those.
| If somebody wants to convince me that the WG will approve of that work
| I'm game to add it to the API spec.
Add it to the drafts now, so the API can be considered, on the assumption
that the specs will be accepted. It takes no time at all to yank that
part if that turns out to be an unwarranted assumption, but quite a long
time of review and updates to add it later if it turns out to be needed.
The name lookups spec in particular needs attention, as it needs to be
determined just how the name that is returned is obtained. Is it always
to be the same value as hostname(2) or can a node set one name to be used
as the result of hostname() (to be used in local log reports, prompts, ...)
and another to be returned to other nodes? No opinion at the minute,
just a question that needs an answer.
| > 4. Access to IPv6 and Extension Headers
| What do others think?
| Should we specify this amount of detail?
Yes. That's one of the most important factors in an API spec - what
state the world will be left in when things go wrong. Otherwise, on
any error, the only option is to close everything down and start again.
Often that's not practical.
| > 6.3. Specifying/Receiving the Hop Limit
| I'll add that.
| Using a zero length option should also work.
Pick one preferred way, and doc that one, not several variations that
all should work.
| If you don't know the number of hops before starting to build the routing
| header you don't know how much memory to allocate for the option/ancillary
| data.
What this leads to is the question of who is responsible for the accounting.
That can be either way - it can be done inside the API, or by the application.
A decision just needs to be made (doing it inside the API functions makes for
a simpler interface, but generally one with greater overheads).
| The API isn't really designed to deal with anything but the recommended
| way of doing extension headers i.e. at most one hbh header,
| at most one destination header before a routing header,
Yes - the "get the header by name" type interface is fine for some
applications, but not nearly powerful enough in general, what is most
likely needed is a "get the next header" interface, which returns the
header type, its length, and its data, as well as a cookie to hand to
the API the next time it is called (0 for the first call) so the API
knows where it was up to in the list. The caller should provide space
for the data - with as much as fits being returned (the returned length
will indicate whether all of the data was included or not - by passing
a data buffer length of 0 the application just gets the header type/length
info back, so it can see what headers exist, and how big they are).
With that, the "get the routing header" can be implemented as library
routines rather than via the interface to the stack if desired.
| While the receive side could provide more I don't see any reason to specify
| that in the API.
if anything, this is what the API ought be specifying, that's more general
and more useful than the "get the routing header" types functions. Knowing
what is in a header is typically only going to provide precise info as to
what it all means when the position in the sequence of headers, and often,
the actual data in the other headers, is examined.
| (But if I ever felt the urge to implement something like that
| having one ancillary data item per extension header would make the most
| sense - and keeping the ancillary data items in the order the extension
| headers were received in the packet.)
Perhaps - that's going to return the whole thing to the app in one hit,
right? That would be appropriate for some apps, but it makes it hard to
work out how to provide adequate buffers.
| > 8.2. Sending Hop-by-Hop Options
| > What should the kernel do if an ancillary data contains multiple
| > IPV6_HOPOPTS objects?
|
| I don't really care and I don't see a good reason for nailing down
| this behavior in the specification. "Implementation defined".
That seems reasonable - it is an "only buggy apps do that" type thing.
But the doc needs to actually say that, not just ignore it.
| > 9.1. Receiving Destination Options
| > A same kind of question of receiving multiple routing headers can be
| > applied to the destination options header as well;
| And the same type of answer applies.
Yes, the API needs to be able to deal with any sequence of known header
types (other than HBH, which is very precisely defined to make it easier
for the routers).
| > 9.2. Sending Destination Options
| > What should the kernel do if an ancillary data contains multiple
| > IPV6_DSTOPTS or IPV6_RTHDRDSTOPTS objects?
| Implementation defined.
This one is probably going to depend on what the API for sending
an arbitrary header sequence looks like.
| > 10.4. inet6_opt_set_val
| While I see the point this statement in RFC 2460
| o One desirable feature is that any multi-octet fields within the
| Option Data area of an option be aligned on their natural
| boundaries, i.e., fields of width n octets should be placed at
| an integer multiple of n octets from the start of the Hop-by-
| Hop or Destination Options header, for n = 1, 2, 4, or 8.
| seems to imply that those are the only supported sizes of the
| option data.
That's not how I read it. I read it as requiring that an option that
happens to be 1 2 4 or 8 bytes should be naturally aligned, whereas options
of other lengths go wherever they best fit.
In practice, whenever a new option is defined, its layout will be specified
by those who define it - the 2460 comment is just trying to guide those
designers to "do the right thing". But they will end up doing whatever
best suits the demands of the option they're creating, and if that means
defining a 7 byte option, that's what will happen - or an option containing
a 2 byte field followed by a 4 byte field, with 2 bytes of trailing padding
(so the 4 byte field is not aligned). Nothing we do now can prevent that
from happening.
| If we don't have that constraint you could interpret the above to mean that
| a 5 octet value should be aligned on its natural boundary i.e. a 5 octet
| alignment.
The "for n = ..." constraint avoids that conclusion. It makes it clear that
the alignment only applies to data items of those lengths.
| So if somebody is designing options with data items that are not a power
| of two in size they need to decide which power of two they need for
| alignment.
Yes, exactly - or more correctly, they need to define the layout of the
option data. As does anyone designing an option.
| While the function doesn't know the alignment of future option content
| it could verify that they have natural alignment i.e. that an N octet
| field (for N = 1,2,4,8) is aligned on an N octet boundary.
That's probably not a good idea - just in case some future spec, for
what are good reasons at the time, decides to do away with that suggestion
from 2460. It is only a suggestion after all (and cannot possibly be more).
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
