Subject: Re: Comments on 2292bis (Adv. API)

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Sep 1999 14:54:54 -0700 (PDT)

I'm catching up on old email making sure I have all the 2292bis issues
written down.

> For the case above the implementation can define a pointer to the addresses
> in the routing header and use that pointer to reference all the addresses. 
> It will get rid of the cast you showed.

If we remove the ip6r0_addr field there will still be one case needed
in the applications (assuming they don't use the inet6_rth_ functions)
to get the pointer to the array of addresses.
But I'll go ahead and remove this field.

> > Spec already says "By default, this socket option is disabled."
> > The option has no meaning for ICMPv6 sockets since they always do their
> > checksum.
> > 
> 
> Could you state that in the spec?

Will do.

> After a closer look at the option processing, I found that there is an
> ambiguity between 2292 and 2292bis.  In particular, the ambiguity exists with
> IPV6_HOPLIMIT option.  With the 2292, this was an 'on/off' options.  With
> 2292bis sticky options, this now takes the actually hop limit itself.  If the
> implementaion decides to support both specs, how is it to pick which option
> to set (both values are int)?

Go point.
I'll remove the 2292 compatibility attempt since I haven't heard one voice 
asking that we keep it.

> The problem that we saw with this specification is that it heavily depends
> on Appendix B of 2460.  In particular that the fields have to be ordered by
> size.  If someone does not follow this specification then the API as it
> stands right now will not be able to calculate allignment function correctly.
> For example, considere these 2 options:
> 
> OPT1:(doesn't follow Appendix B)		OPT2:
> 	Length = 12					Length = 12
> 	Data1 = 8 bytes					Data1 = 4 bytes
> 	Data2 = 4 bytes					Data2 = 4 bytes
> 							Data3 = 4 bytes
> 
> The alignment of the end of both of these options is 4 since the last data
> field is only 4 bytes.  If that is the case, then when setting up OPT1, the
> Data1 field may not be aligned on a natural boundry and may break the
> applications and cause
> alignment faults.
> 
> If we were to fix OPT1 to follow Appendix B, everything works fine.

At a minimum I'll make then spec clearly state this assumption.

> There reason we are advocating for 'alignX' and 'alignY' as arguments to the
> API is that they will already be defined in the Option Specification and
> easily used ('length' will be the 3 argument).  If the Option Specification
> does not follow Appendix B (it doesn't have to), then this API will still
> align the data correctly and conserve as much space as possible (one of the
> goals stated in 2460).

Are you arguing that there is a benefit in defining options differently
than the recommendation in 2460 i.e. that this will save space?
That doesn't appear to be the case for a single option in an extension header.
If you have multiple options you might save space.

Here is what I think is the worst case with 2 options:
Imagine OPT1 with two 4 byte fields and one 8 byte field
and OPT2 with one 2 byte field and one 8 byte field.
The rules state that the layout should be:
	OPT1 type, len
		4 byte field
		4 byte field
		8 byte field
	OPT2 type len
		2 byte field
		8 byte field

But if you put them in an extension header you end up with
	ehdr nexthop, len
	4 pad bytes
	OPT1
	4 pad bytes
	OPT2

But if you allowed OPT1 to be layed out as
	OPT1 type, len
		4 byte field
		8 byte field
		4 byte field

You could handle OPT1 + OPT2 without any padding (saving 8 bytes).

But as appendix B in 2260 states the assumption is that there is
usually only one option in an extension header.

> Yes, I was refering to sticky otions.  It looks like you are advocating
> caching the options.  In you implementation if the user were to set both
> IPV6_RTHDRDSTOPTS and IPV6_RTHDR options, and then unset IPV6_RTHDR, you
> would still have the IPV6_RTHDRDSTOPTS option set, but will ignore it.  Is my
> understanding correct?

That is what our current implementation does.
While I'm not strongly advocating this it is simple to implement
and allows the application to set options in any order (i.e. the
application can issue a setsockopt for IPV6_RTHDRDSTOPTS before the
setsockopt for IPV6_RTHDR).
An alternative was suggested by Tim: make IPV6_RTHDRDSTOPTS just specify a
second destination header which is sent whether or not there is a routing
header. This is as easy to implement as far as I can tell, but it doesn't
quite match the IPV6_RTHDRDSTOPTS name. It would make sense to change the
name to e.g. IPV6_DSTOPTS2 if we go this path.

> > I guess zero is the only too small value that is a multiple of 8.
> > Thus it is really"
> >         If the extlen value is not a positive multiple of 8 the
> >         function fails and returns -1.
> > 
> 
> Will this be in the new spec?

Yes.

   Erik

--------------------------------------------------------------------
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: Vladislav Yasevich <[email-masked]>
Date: Fri, 17 Sep 1999 13:24:30 -0400

> than the recommendation in 2460 i.e. that this will save space?

No, the argument was that by replacing 'align' with 'alignX' and 'alignY' we
illiminate the dependency on Appendix B of 2460.  Granted, we see the benefit
only if the option is NOT designed to follow Appendix B and when multiple such
options are specified.  I don't know how common this particular case will be,
but why restrict the API.

> name to e.g. IPV6_DSTOPTS2 if we go this path.

Thanks for clearing this up.  Given the options, I would pick your 
implementation.

>    Erik

Thanks
-vlad

+++++++++++++++++++++++++++++++
Vladislav Yasevich
Compaq Computer Corp.
110 Spit Brook Rd ZK03-3/T07
Nashua, NH 03062
(603) 884-1079
--------------------------------------------------------------------
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]
--------------------------------------------------------------------