Subject: [Mip6] Question about draft-sugimoto-mip6-pfkey-migrate

From: Keiichi SHIMA <[email-masked]>
Date: Wed, 31 Jan 2007 17:50:05 +0900

Hello,

I have a question about the PF_KEY extension draft (draft-sugimoto- 
mip6-pfkey-migrate).

The draft proposes SADB_ACQUIRE message extension to include the  
entire (or the beginning of the) IP header that triggered the acquire  
message.  The reason of the extension described in the draft is to  
extract the CoA of an MN that is used for  IKE communication.

The question is that, do we need to include the entire (or the  
beginning of the) packet to the acquire message?  If the goal is to  
provide the CoA information to an IKE program, then why can't we  
simply notify the address?

Including a raw packet has two drawbacks.

1. The IKE program that supports this extension has to parse the raw  
IPv6 packet to extract a CoA.

2. Some kernel implementations do not have the final packet structure  
when sending an ACQUIRE message.  In these implementations, they only  
have abstract information  to construct the packet, and the packet  
will be constructed just before it is sent.  In this case, the kernel  
must create a packet before sending an ACQUIRE message, that is not  
necessary in their design.

What do you think?

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
WIDE Project <[email-masked]>

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 31 Jan 2007 11:26:57 +0100

In your previous mail you wrote:

   
   
=> in fact you have the choice between to decode the packet in the kernel
or in the application. I am in favor of the first option for many
reasons including:
 - it is better to keep the kernel as simple as possible
  (i.e., KISS principle)
 - we don't know a priori what applications will need.

   
=> someone has to do this.

=> to give the final structure doesn't matter as the decoding code is
supposed to be kernel dependent (even if there are no many choice and
it is easy to get one code working for many kernels). The only key point
is to give to the application enough information, the way they are
organized is a detail as soon as the application knows it!

Thanks

[email-masked]

PS: if you believe it can be good, can you propose some text to explain
this to add in the I-D?