Subject: [dhcwg] RE: Issue/Solution for Confirm-Reply - Remainder

From: "S.SenthilKumar (Huawei)" <[email-masked]>
Date: Fri, 31 Aug 2007 14:20:54 +0530

Dear All

I would appreciate if somebody could clarify or Provide pointers for the issue regarding Confirm-Reply (RFC3315) that I had sent earlier (Refer the attached mail).

Thanking you,

Regards
SenthilKumar.S

Disclaimer: This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

-----Original Message-----
From: S.SenthilKumar (Huawei) [mailto:[email-masked]] 
Sent: Monday, August 27, 2007 5:48 PM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: FW: Issue/Solution for Confirm-Reply

Dear All
Please suggest how to resolve this issue.
Configuration
　　Assume that IA1, IA2 and IA3 were present in the same interface
　　* IA1 has binding with Server S1 and K1 is the DAP key in use for the current session
　　* IA2 has binding with Server S2 and K2 is the DAP key in use for the current session
　　* IA3 has binding with Server S3 and No DAP Authentication (Client has accepted Advertise without Authentication Option as it is enabled in the local configuration)
　　* And all the IAs leased.

As per RFC, Confirm message has to be sent to the server containing all the IAs present in the interface. But in this case how, Which Key has to be used, whether DAP Option has to be present. 

18.1.2. Creation and Transmission of Confirm Messages
The client MUST include a Client Identifier option to identify itself to the server.  The client includes IA options for all of the IAs assigned to the interface for which the Confirm message is being sent.  The IA options include all of the addresses the client currently has associated with those IAs.  The client SHOULD set the T1 and T2 fields in any IA_NA options, and the preferred-lifetime and valid-lifetime fields in the IA Address options to 0, as the server will ignore these fields.

Solution I had devised is that Confirm can be send on the basics of IA i.e confirm will carry only one IA (IA_NA or IA_TA)

Advantages of the solution
1. If Not on link status is received in the Reply received in response to Confirm, Only the address present in the IA will be released
2. Authentication – Confirm-Reply transaction will also be part of the session (Solicit-Advertise till Release/Decline of the last address)
Disadvantages of the solution
1. Multiple Confirm message will be send from the client (Also loads the server)
2. RFC Conformance – I’m not sure about this as “ALL” is mentioned in the RFC.

Let me know your views.

Thanking you,

Regards
SenthilKumar.S

Disclaimer: This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

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