Subject: [Mip6] Comment on draft-ietf-mip6-mipext-advapi-03.txt

From: Ville Nuorvala <[email-masked]>
Date: Wed, 6 Oct 2004 16:13:31 +0300 (EEST)

Hi Samita,

this is just a minor issue, but looking at struct ip6_opt_home_address and
struct ip6_rthdr2, I notice notice the home address field is defined as a
uint8_t array in the first one and a struct in6_addr in the latter one.
Why not also define ip6oha_addr as an in6_addr?

Regards,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: [email-masked], phone: +358 (0)9 451 5257

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

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 7 Oct 2004 12:05:40 -0700 (PDT)

Hi Ville,

Thanks for reviewing the API draft.
> Why not also define ip6oha_addr as an in6_addr?

I think it was brought up before at last Cthon meeting. Originally the
home-address was defined as 16 uint8 quantity because that would be
easy to copy byte by byte in the destination option without any alignment.
In ip6_rthdr2,
home-address always starts from the 4n byte boundary so in6_addr
was used as in6_addr might be system dependent.

Example (rfc2553):
   struct in6_addr {
        union {
            uint8_t  _S6_u8[16];
            uint32_t _S6_u32[4];
            uint64_t _S6_u64[2];
        } _S6_un;
   };

However, in RFC3775, the alignment requirement for home-address option
is 8n+6 - hence it requires home-address to start from a 4byte boundary
as well in the home-address option.  

At the time of last discussion, we decided to keep the way it is, i.e.
uint8   ip6oha_addr[16];

-Samita