Subject: [Mip6] [issue26] Discuss comments by Bill Fenner (2)

From: Basavaraj Patil <[email-masked]>
Date: Thu, 01 Sep 2005 21:03:47 +0000

New submission from Basavaraj Patil <[email-masked]>:

I wonder about the need for

    int inet6_rth_gettype(const void *bp);

The advanced API gives examples of, e.g., accessing rth->ip6r_segleft directly
in an ip6_rthdr; why not access rth->ip6r_type directly too?

Related to Sam's comments:
        uint8_t          ip6oha_addr[16];  /* Home Address */
It'd be really nice if this could be a struct in6_addr, but presumably it's this
way because struct padding gets badly in the way given the 8n+6 alignment of
this option.  It'd be nice if somehow the struct could contain the 6 so that you
could use the aligned struct in6_addr.  Is this the first struct defined for an
option with alignment requirements like this?

Moving the HA option automatically is a little weird; I'm uncomfortable about
asking the kernel to parse the IPV6_DSTOPTS and move an HA option if found
(especially with an 8n+6 padding, if there are other options packed in the
IPV6_DSTOPTS things could get weird) - if this is a one-off then I'm inclined to
let it go, but could there be another use for placing options between Routing
and Frag headers?  In which case, would it be better to define another
IPV6_???DSTOPTS option?

----------
category: Editorial
draft: draft-ietf-mip6-mipext-advapi
messages: 92
nosy: bpatil
priority: Should fix
status: No discussion
title: Discuss comments by Bill Fenner (2)

_________________________________________________
Mip6 issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/mip6/issue26>
_________________________________________________

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6