Subject: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05

From: Suresh Krishnan <[email-masked]>
Date: Mon, 24 Sep 2007 19:31:46 -0400

Hi Authors,
   I have tried to do a complete review of the PMIP document. If any of
these comments have been fixed in -06 please feel free to ignore them.

Thanks
Suresh

Major
=====

Overall
=======

Link Local address of MAG
=========================
When an MN moves from one link to another how does it switch default
routers to the new MAG. The link local addresses of the old MAG and the
new MAG will most likely be different and hence unless nud removes the
old mag the mn will try to reach it even after handover. Or it is
assumed that all the MAGs will have the same LL address? Is this is an
assumption, it needs to be stated.

Timestamp synchronization
=========================
I read through the timestamp approach for synchronization and it is
unclear why the MAG and the LMA need to sync their clocks. I think it is
sufficient for MAGs to sync between themselves. Why does the LMA need to
check if the MAGs timestamp is different from its timestamp?

LMA Address acquisition
=======================
Why is the LMA address a mandatory part of the MN profile? And why is it
the ONLY allowed method for acquiring an LMA address? Can't the MAG use
some other method to acquire the LMA address (static config, DNS...). I
think this is overly restrictive.

Section 4
=========
"IKEv2 [RFC-4306] SHOULD be used to setup security associations
  between the mobile access gateway and the local mobility anchor to
  protect the Proxy Binding Update and Proxy Binding Acknowledgement
  messages."

This is a significant departure from RFC3775 where this was a MAY. What
is the reasoning behind making this a SHOULD? I believe manual config
should be a MUST and automatic key mgmt should be a MAY.

P flag
======

I do not see any text in the expected LMA behavior to CHECK for the
presence of the P flag in the received BU. I think this should be added.

Section 5.3: Binding De-registration
====================================
"Upon accepting the Proxy Binding Update request for a mobile node,
  with the lifetime value of zero, the local mobility anchor MUST
  wait for MinDelayBeforeBCEDelete amount of time, before it deletes
  the mobile node's Binding Cache entry."

What is the purpose for having a timer to delete a BCE? I see no reason
at all in waiting. If this is being done to prevent considering a
following BU as an initial registration ( I suspect this is the case)
please extend the conceptual data structure to add a deleted flag
instead of using a timer.

The following step directly contradicts this step as well. Make sure
that they are consistent.

Section 5.3: PBA formation
==========================
" If the Status field is set to a value greater less than 128, i.e.
   if the binding request was rejected, then the prefix value in the
   Home Network Prefix option MUST be set to the prefix value from
   the received Home Network Prefix option."

This does not cover the case where the PBU did not contain a HNP option
(rejection with error 129). So the text needs to be extended in order to
clarify the behavior in such case. I would suggest the following text

" If the Status field is set to a value greater less than 128, i.e.
   if the binding request was rejected, then the prefix value in the
   Home Network Prefix option MUST be set to the prefix value from
   the received Home Network Prefix option. If the received PBU did
   not contain a Home Network Prefix option, then the HNP option MUST
   NOT be included. "

This also implies that the HNP field becomes optional in the PBA.

Section 6.8
===========
I am not sure how the odds of collision are arrived at. If there is a
reference please put it in here. However I look at it, the number does
not look too good to me. Anyway, this feels totally out of place in the
PMIP spec. Thus, as an alternative, you can remove the whole text
without losing anything.

Section 6.9.1
=============
"o  If the received Proxy Binding Acknowledgement message has the
     Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX
     (Not authorized for that prefix), the mobile access gateway SHOULD
     try to request for that prefix in the binding registration
     request, only after it learned the validity of that prefix."

I am not sure why the MAG SHOULD try again. If this error case occurs, I
think that the MAG SHOULD do one of the following

1) Deny mobility service to the MN
2) Send a PBU with the null hnp to request a new prefix allocation

Section 6.9.3
=============
" o  If Timestamp based scheme is in use, the retransmitted Proxy
       Binding Update messages MUST use the latest timestamp.  If
       Sequence number scheme is in use, the retransmitted Proxy Binding
       Update messages MUST use a Sequence Number value greater than that
       used for the previous transmission of this Proxy Binding Update
       message, just as specified in [RFC-3775]."

I completely disagree with this. I think if a PBU is retransmitted it
MUST use the same timestamp as the first time around. Otherwise we will
run into ordering problems.

Section 6.11
============

I am not sure how the MAG can send the HNP of the MN in the link-address
field of the DHCP relay message since the link-address field does not
contain a prefix length. Is there an implicit assumption that the prefix
will be 64 bits in length?

IANA Considerations
===================

Don't forget to request the assignment of the P bit in the BU and BA
messages in the IANA considerations section.

Minor
=====

Section 3
=========

Figure 3: The detach flow is not explained at all. If the detach flow
needs to stay in the figure, it needs to be elaborated in the following
text. It is probably not relevant in this figure either, since the BCE
gets replaced by the new PBU anyway.

Section 5.3
===========

The following two bullets refer to section 4.0 that does not exist. Can
you insert the reference to the right section here. (I am assuming it is
section 4 but I am not sure)

    o  The local mobility anchor MUST authenticate the Proxy Binding
       Update request as described in Section 4.0.  It MUST use the SPI
       in the IPSec header [RFC-4306] of the received packet for locating
       the security association needed for authenticating the Proxy
       Binding Update request.

    o  The local mobility anchor MUST apply the required policy checks,
       as explained in Section 4.0, to verify the sender is a trusted
       mobile access gateway, authorized to send proxy binding
       registration requests on behalf of this mobile node

Section 5.3: Binding De-registration
====================================
"the local mobility anchor MAY either choose to ignore
  the request or send a valid Proxy Binding Acknowledgement message
  with the Status field set to 0 (Proxy Binding Update Accepted"

as opposed to doing what else? I think this whole point is redundant.
Recommend one of these options or remove the whole paragraph.

Section 5.5.2 : Forwarding considerations
=========================================

Point 1 (Intercepting packets ...)

This point explains plain IP routing. I am not sure what it has to do
with PMIP. Is there any reason this point needs to be explicitly mentioned?

Section 6.8
===========
The last paragraph states
" This issue is not relevant to the mobile node's global address.
  Since, there is a unique home network prefix for each mobile node,
  the uniqueness for the mobile node's global address is assured on the
  access link"

By turning on the DNASameLinkDADFlag the MN will do DAD on the global
address as well. The flag is not exclusive to LL addresses.I think this
should be clarified.

Section 6.10.4
==============

The config variable EnableMAGLocalRouting is not mentioned here. Can you
add it here as it is very relevant here.

Section 8.1
===========

Add references to HMIP and nemo for the M and R flags as they are not
defined in RFC3775 as implied by the text.

Editorial
=========

Section 2.2
===========
LMA:
"It is the topological anchor point for
the mobile node's home network prefix and is the entity that
manages the mobile node's reachability state."

I am not sure what the phrase "manages the MN's reachability state"
means. Can you please clarify or remove this phrase.

Section 3
=========
paragraph 3 line 2

Replace "The local mobility is" with "The local mobility anchor is"

Section 5.5.1
=============
There is redundant text regarding shared tunnels between MNs.

point 3: "The created tunnel may be shared
       with other mobile nodes attached to the same mobile access gateway
       and with the local mobility anchor having a Binding Cache entry
       for those mobile nodes."

point 4: "The tunnel between the local mobility anchor and the mobile access
       gateway is typically a shared tunnel and can be used for routing
       traffic streams for different mobile nodes attached to the same
       mobile access gateway."

I think point 4 can safely be removed

Section 6.9.1
=============
Binding Re-Registration:
  "the value in the Link-local Address option may be set to ALL_ZERO
   or to the link-local address of the mobile node."

This has to be a normative MAY.

Section 6.9.2
=============
Router Solicitations:
"However, it MAY choose to advertise a local visitor
  network prefix to enable the mobile node for simple IPv6 access."

Replace "visitor" with "visited"

References
==========

Please update references for all the bis RFCs 2461,2462,3041 etc. so
that the RFC editor will replace them with the latest RFCs
(4861,4862,4941...)

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Sep 2007 17:13:23 -0700

Hi Suresh,

A few random replies. Assume Sri will respond in detail :)

> Link Local address of MAG

It is assumed that the same link local address is used for a particular 
mobile node across all MAGs. This is stored at the LMA and retrieved by 
the new MAG. This is described in the document.

> should be a MUST and automatic key mgmt should be a MAY.

At the time RFC 3775 was written, IKEv1 was on the "way out". Currently 
IKEv2 seems to be the default for setting up IPsec security associations.

> presence of the P flag in the received BU. I think this should be added.

hmmm.... the LMA uses the 'P' flag to recognize that it is a proxy 
binding update from a MAG. Otherwise the LMA assumes it is a MIPv6 
binding update from a MIPv6 mobile node. So the LMA checks for the 'P' 
flag all the time.

> Section 5.3: Binding De-registration

This is to make sure you don't release the home address/home network 
prefix as soon as a MAG de-registers. The proxy binding update from the 
new MAG may have been delayed.

> Section 6.9.3

No. It should always use the latest timestamp value. Otherwise the LMA 
would not be able to distinguish between a lost Proxy BU being 
re-transmitted from a replayed proxy BU.

> IANA Considerations

The binding update flags are not maintained by the IANA. The respective 
documents define the flags and their positions.

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 24 Sep 2007 22:01:20 -0700

Hi Suresh,

Thanks for the review. Please see inline.

Sri 

> Link Local address of MAG

The MN section has the text on this. The DR needs to be timeout
or in links where SEND is not deployed, a fixed linkeed-local
address can be configured on all MAG interfaces. One or more
ways to deal with it. MAG can also withdraw the prev AR.

> Timestamp synchronization

This is for convering the case, where the MN boots on a bad MAG
where the time is like 5 hours ahead. If LMA does not do the
basic sanity check and accepts the PBU, all subsequent PBU's
from the other MAG's where the MN moves to will have older TS.
We have discussed this thread to death. No worries on this logic.

> LMA Address acquisition

Hmm ... I can move the LMAA to the optional section. Fine, if
we think there are other methods of LMA discovery.

> should be a MUST and automatic key mgmt should be a MAY.

The thought was that the SA is protecting multiple MN flows and its
important that the SA's are setup dynamically using IKEv2 and with
the proper rekeying properties. Also, as Vijay says, when 3775 came
out not many mobile stacks have IPsec support and that could be
the reason for not mandating IKE. 

> presence of the P flag in the received BU. I think this 

The message with the "P" flag is the PBU. The whole signaling logic
is tied to this message.

> Section 5.3: Binding De-registration

For covering the make-before-break case. It cant be just a flag,
its a time sensitive operation.

> Section 5.3: PBA formation

Ok. This is a good point. The idea of rejecting a message because
it does not have a specific option, conflicts with the mandatory 
option requirement. I think, the LMA should simply ignore a message
if a specific required option is not present. I will fix it.

> Section 6.8

Ok. I rephrased it.

> Section 6.9.1

It can be upto the implementation. We are just saying, the MAG 
should not keep trying and trying requesting the same prefix, while
the LMA keeps rejecting the request.

> Section 6.9.3

I dont think it will create any ordering problems. The message is
generated at a different time. If it uses old timestamp, it breaks
the LMA sanity check rule.

> Section 6.11

This is per 3315. I will look into the format.

> IANA Considerations

As Vijay pointed out, IANA does not manage this part.

> gets replaced by the new PBU anyway.

Ok

> Section 5.3

It points to the PMIP6 security model, described in Sec 4.

> Section 5.3: Binding De-registration

Ignore the request or Send the reply 
Will rephrase it.

> Section 5.5.2 : Forwarding considerations

Well, some basic guidance. Not every one is an expert
in forwarding :)

> Section 6.8

Ok

> Section 6.10.4

Ok

> Section 8.1

ok

> Section 2.2

ok

> Replace "The local mobility is" with "The local mobility anchor is"

fixed

> Section 5.5.1

ok

> Section 6.9.1

ok

> Section 6.9.2

ok

> References

ok

Thanks for the review.

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Sep 2007 14:29:30 +0200

Sri Gundavelli wrote:
[...]
>> Section 6.11 ============
>> 
>> I am not sure how the MAG can send the HNP of the MN in the 
>> link-address field of the DHCP relay message since the link-address
>>  field does not contain a prefix length. Is there an implicit 
>> assumption that the prefix will be 64 bits in length?
>> 
> 

I think here may be an error of interpretation or of specification.

RFC3315:
> If the relay agent received the message to be relayed from a client, 
> the relay agent places a global or site-scoped address with a prefix 
> assigned to the link on which the client should be assigned an 
> address in the link-address field.

I think it wrongly says "with a prefix".  Because: (1) it makes people
think there is a prefix length in that field, (2) the DHCP RELAY-FORWARD
doesn't encode a prefix length (3315 pp 18) (3) wireshark doesn't show a
prefix length field, (4) Dibbler implementation doesn't encode a prefix
length but a full /128 address in that field, it's the address of the
Relay interface on which a mobile attaches.

This is why I suggest we discuss this use of DHCP separately.

Let's define first the problem: why does the MAG DHCP Relay need to
insert the prefix of the mobile in the RELAY-FORWARD message?  How can
we do it (other than link-address field)?

If you don't think we should discuss it and continue keeping the use of 
link-address field as you suggest then I suggest to move it into an 
appendix.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Sep 2007 15:11:00 +0200

Suresh Krishnan wrote:
[...]
> Timestamp synchronization

This is a tough question, but I believe they should have their times 
synchronized unless a method like the one proposed by Ahmad previously, 
or maybe mixing a uniqid (MAC) in the timestamp - are used.

I think this is a good topic to ponder over, and apparently at IETF 
there may even be a place to discuss these aspects related to time.

http://www.ietf.org/internet-drafts/draft-bryant-tictoc-probstat-01.txt

Alex

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 25 Sep 2007 10:08:34 -0400

Hi Vijay,
   Thanks for the quick response. My comments inline.

Cheers
Suresh

> the new MAG. This is described in the document.

I was talking about the LL address of the MAG (not the MN).

> IKEv2 seems to be the default for setting up IPsec security associations.

OK.

> binding update from a MIPv6 mobile node. So the LMA checks for the 'P' 

I know it. You know it. But it is not in the document :-). A simple note 
in section 5.3 would do.

"o  If the P flag is not set in the Proxy Binding Update request,
     the local mobility anchor MUST discard the Proxy Binding Update
     and log an error. "

Also note that the definition of a PBU DOES NOT mention the P flag either.

> new MAG may have been delayed.

What happens to the data that is received in this time period? Why will 
this be unnecessarily carried to the MAG before being dropped? That is 
my concern. That is why I suggested marking it as deleted (which will 
stop the data flow) and do a cleaning sweep periodically.

> re-transmitted from a replayed proxy BU.

I cannot see how this works. Consider this scenario.

MN moves from MAG1 to MAG2 and then to MAG3.

M1: MAG2 sends PBU with Timestamp T (This is lost)
M2: MAG3 sends PBU with Timestamp T+x (This arrives at LMA and updates 
the binding cache on the LMA)
M3: MAG2 retransmits PBU with Timestamp T+x+y(This arrives at LMA. LMA 
sees that the timestamp is later than the current one and then replaces 
the current entry in the Binding Cache)

MN loses connectivity.

> documents define the flags and their positions.

OK.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 25 Sep 2007 10:18:33 -0400

Hi Sri,
   I am removing things that we agreed on.

Cheers
Suresh

OK.

> We have discussed this thread to death. No worries on this logic.

But isn't this still the case where the MAGs have to be synced and not 
the LMAs. I am thinking about roaming scenarios where the MAGs can and 
will be connected to multiple and keeping the time in sync between the 
MAGs and the LMAs becomes a big issue.

OK.

OK.

> The message with the "P" flag is the PBU. The whole signaling logic

As I said in my mail to Vijay, I know this is the case, but it is not 
mentioned anywhere in the document. Explaining this in either the 
terminology for the PBU ("a PBU will have the P flag set...") or adding 
a checking step in the LMA operation will do.

> its a time sensitive operation.

In a make-before-break case, the new PBU will arrive BEFORE the 
deregistration PBU will arrive. I am not sure I see the applicability of 
the timer to this case. Can you please clarify.

OK.

> the LMA sanity check rule.

Please see my mail to Vijay on this subject where I explained a scenario.

>> link-address

OK.

OK.

OK.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 25 Sep 2007 12:43:55 -0500

> the current entry in the Binding Cache)

[Ahmad]
Hi Suresh,

The scenario you just mentioned is not very much different than what has
been discussed before on this mailing list and offline. Please let me
summarize this as follows:

1. This scenario is related to a race condition that has been identified
a long time ago and a solution has been proposed and identified for it
but for a reason or another some people does not like to document the
solution in PMIPv6 draft.

2. Having said the above, the scenario at hand as you mentioned can
happen due to a combination of more than two events that accidentally
happens at the same time:

2.1. A MN1 is attached to MAG1 and has a PMIP session with a BCE (P-CoA1
<-> P-HoA1) at LMA1.
2.2. MN1 PMIP session is about to expire and MAG1 sends a
re-registration P-BU2 to extends the MN1 PMIP session lifetime.
2.2.1. Currently: PMIPv6 draft requires the MAG to make sure the MN is
attached before sending a re-registration P-BU.
2.3. At almost the same time or soon after MAG1 sends the
re-registration P-BU2, MN moves to MAG3 and does all access
authentication and all the good stuff that enables MAG2 to send an
initial P-BU3 to update the MN BCE with (P-CoA2 <-> P-HoA1) at LMA1.
2.4. Not only that, but this scenario requires one of the followings
(P-BU2 is either delayed or lost) and P-BU3 arrives first.
2.5. I am not saying that this scenario is impossible but it rarely
could happen. But that is fine.
2.6. When LMA receives P-BU3, LMA clearly can identify that the MN is
moving from MAG1 to MAG2.

The details of the solution starts here and it will address all
scenarios:

3. LMA creates a tentative BCE for MN1 (P-CoA2 <-> P-HoA1) and starts
sending traffic to the new P-CoA2.
4. If LMA receive the P-BU2 (the one delayed or the retransmitted after
the first lost) within the lifetime of the tentative BCE, LMA does the
following:

4.1. LMA rejects the P-BU2 with P-BA2 and code "MN-Handoff-in-Progress"
for example, or we can call it whatever.
4.2. LMA keeps the traffic pointing to (P-CoA2 <-> P-HoA1)
4.3. When MAG receives the P-BA2, MAG cancel the MN current
re-registration states and verifies if the MN is still attached before
sending any new P-BU.
4.4. When the BCE timer expires, LMA replace the old BCE with the
tentative BCE.

Tentative BCE can be as simple as having a simple timer running.

The funny thing is that I heard some people are ok to leave such a
scenario out-of-scope and not document the solution in PMIPv6 draft. I
am not sure why people think that way but it is an opinion. :-(

This solution should address the race condition that you just
highlighted.

Best Regards,
Ahmad

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 25 Sep 2007 15:24:46 -0400

Hi Ahmad,
   I see the problem you are mentioning and is very valid and I think 
your solution is a reasonable one for the problem that you mentioned. 
But unfortunately the problem is not the one that I raised in my 
comments. The main differences between the scenarios are

* In my scenario, only one event needs to occur for problems to occur 
(Lost PBU only, no re-ordering necessary)
* No BCE was ever created for the MAG whose PBU arrives second(MAG2). In 
your scenario MAG1 ONCE HAD a valid BCE.
* In your scenario the problem causing PBU is a refresh PBU (after 
lifetime expires) and in mine it is just a retransmission. Note that 
there is no requirement for the MAG to check for MN's attachment before 
RETRANSMITTING a PBU.

I think the scenarios are both race conditions, but that is where the 
similarity ends. I do not think the same solution applies to both. Do 
you agree?

Cheers
Suresh

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 25 Sep 2007 14:44:20 -0500

Hi Suresh,

I still believe it is the same problem and the same solution is
applicable as follows:

**** I cut and pasted your scenario and added my comments. ******

At the LMA, as per your scenario, MN has a BCE with the following
(P-CoA1 (belongs to MAG1) <-> P-HoA1)

1. M1: MAG2 sends PBU with Timestamp T (This is lost)
[Ahmad]
Ok.

2. M2: MAG3 sends PBU with Timestamp T+x (This arrives at LMA and
updates the binding cache on the LMA)
[Ahmad]
i. Since LMA did not receive M1, M2 is considered a handoff from MAG1 to
MAG3. right?
ii. LMA will create a tentative BCE with (P-CoA3 <-> P-HoA1). Right?

3. M3: MAG2 retransmits PBU with Timestamp T+x+y(This arrives at LMA. 
LMA sees that the timestamp is later than the current one and then
replaces the current entry in the Binding Cache)

[Ahmad]
Ok, 
i. LMA receive M3 with P-CoA2 and P-HoA1, let us remember that is the
content of the P-BU, while tentative BCE is valid. Right?

ii. Since tentative BCE for this MN at LMA is still valid with (P-CoA3
<-> P-HoA1), i.e. timer did not expire, LMA recognizes that M3 is
happening possibly due to race condition during handoff.
 
iii. LMA rejects M3 with P-BA3 and code "MN-handoff-in-progress".
iv. MAG2 receives P-BA3 with code "MN-handoff-in-progress" and realizes
that the MN is possibly no longer attached to it.

v. MAG2 cancels registration and verifies if the MN is still attached
before sending another P-BU.

So far, I do not see any problem and it should work just fine. 

Do you see any problem in the above?

Best Regards,
Ahmad

> >> MN loses connectivity.
Regards,
Ahmad

> -----Original Message-----
> From: Suresh Krishnan [mailto:[email-masked]] 
> Sent: Tuesday, September 25, 2007 2:25 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Vijay Devarapalli; [email-masked]
> Subject: Re: [netlmm] Suresh's review of 
> draft-ietf-netlmm-proxymip6-05
> 
> Hi Ahmad,
>    I see the problem you are mentioning and is very valid and 
> I think your solution is a reasonable one for the problem 
> that you mentioned. 
> But unfortunately the problem is not the one that I raised in 
> my comments. The main differences between the scenarios are
> 
> * In my scenario, only one event needs to occur for problems 
> to occur (Lost PBU only, no re-ordering necessary)
> * No BCE was ever created for the MAG whose PBU arrives 
> second(MAG2). In your scenario MAG1 ONCE HAD a valid BCE.
> * In your scenario the problem causing PBU is a refresh PBU 
> (after lifetime expires) and in mine it is just a 
> retransmission. Note that there is no requirement for the MAG 
> to check for MN's attachment before RETRANSMITTING a PBU.
> 
> I think the scenarios are both race conditions, but that is 
> where the similarity ends. I do not think the same solution 
> applies to both. Do you agree?
> 
> Cheers
> Suresh
> 
> Ahmad Muhanna wrote:
> >>>> Section 6.9.3
> >>>> =============
> >> M2: MAG3 sends PBU with Timestamp T+x (This arrives at LMA and 
> >> updates the binding cache on the LMA)
> >> M3: MAG2 retransmits PBU with Timestamp T+x+y(This arrives at LMA. 
> >> LMA sees that the timestamp is later than the current one and then 
> >> replaces the current entry in the Binding Cache)
> >>
> >> MN loses connectivity.
> > 
> > [Ahmad]
> > Hi Suresh,
> > 
> > The scenario you just mentioned is not very much different 
> than what 
> > has been discussed before on this mailing list and offline. 
> Please let 
> > me summarize this as follows:
> > 
> > 1. This scenario is related to a race condition that has been 
> > identified a long time ago and a solution has been proposed and 
> > identified for it but for a reason or another some people does not 
> > like to document the solution in PMIPv6 draft.
> > 
> > 2.1. A MN1 is attached to MAG1 and has a PMIP session with a BCE 
> > (P-CoA1 <-> P-HoA1) at LMA1.
> > 4. If LMA receive the P-BU2 (the one delayed or the retransmitted 
> > after the first lost) within the lifetime of the tentative BCE, LMA 
> > does the
> > following:
> > 
> 4.3. When 
> > MAG receives the P-BA2, MAG cancel the MN current re-registration 
> > states and verifies if the MN is still attached before 
> sending any new 
> > P-BU.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 25 Sep 2007 15:52:26 -0400

Hi Ahmad,

> **** I cut and pasted your scenario and added my comments. ******

Thanks a lot for doing this. It makes the discussion easier and more 
productive.

> Do you see any problem in the above?

Yes, I do see a problem. How do you differentiate the two following 
cases with the solution you proposed

MAG1->MAG2->MAG3 (with MAG2 PBU lost, retransmitted and arriving after 
MAG3 PBU) -> Your solution detects this correctly and rejects MAG2 PBU

and

MAG1->MAG3->MAG2 (very quick movement from MAG3->MAG2 all PBUs arrive in 
order) -> Your solution detects this incorrectly and rejects the valid 
MAG2 PBU

Thanks
Suresh

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Sep 2007 15:03:42 -0700

Suresh Krishnan wrote:

>> It is assumed that the same link local address is used for a 
>> particular mobile node across all MAGs. This is stored at the LMA and 
>> retrieved by the new MAG. This is described in the document.
> 

I was talking about that too. :) But I guess my earlier reply was a bit 
confusing. I was trying to say that the same link local address for the 
MAGs is used as the MN moves across the PMIPv6 domain.

>     the local mobility anchor MUST discard the Proxy Binding Update

No. If you have a MIPv6 HA/LMA functionalities co-located, the MIPv6 HA 
would still process the BU assuming it is a regular BU.

>> prefix as soon as a MAG de-registers. The proxy binding update from 
>> the new MAG may have been delayed.
> 
> What happens to the data that is received in this time period? 

Dropped or buffered. It would depend on the LMA implementation.

> the current entry in the Binding Cache)

MAG2 is supposed to check if the MN is still attached to it before 
re-transmitting the Proxy BU.

IMO, using the registration revocation mechanism for PMIPv6 might be the 
cleanest approach. Any loss of connectivity is likely to be temporary 
once we have the registration revocation mechanism for PMIPv6.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 25 Sep 2007 18:54:37 -0700

I think this one is worth taking up on its own thread as well.  Suresh
and I both raised this issue in our reviews and the excerpts below are
from the ongoing discussions based on Suresh's review. 

I have a meta question here.  Replay protection is provided using IPsec,
not using timestamps.  Timestamps are meant for ordering the PBUs and
for that purpose, it really appears to me that retransmitted PBUs need
not change the timestamps.  As I mentioned in my review, that is
desirable from a security perspective.  Even from an ordering
perspective, based on the discussions I've seen here, that seems to be
better.  

What is the problem with retransmissions going out with the same
timestamp value?  Vijay pointed to replay protection and I claim that is
not needed.  Were there other points? 

Thanks,
Vidya

> >>> I completely disagree with this. I think if a PBU is 
> retransmitted 
> >>> it MUST use the same timestamp as the first time around. 
> Otherwise 
> >>> we will run into ordering problems.
> >>
> >> No. It should always use the latest timestamp value. Otherwise the 
> >> LMA would not be able to distinguish between a lost Proxy BU being 
> > sees that the timestamp is later than the current one and then 
> MAG2 is supposed to check if the MN is still attached to it 
> before re-transmitting the Proxy BU.
> 
> IMO, using the registration revocation mechanism for PMIPv6 
> might be the cleanest approach. Any loss of connectivity is 
> likely to be temporary once we have the registration 
> revocation mechanism for PMIPv6.
> 
> Vijay
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 25 Sep 2007 19:17:31 -0700

We are not using timestamps for replay protection. When
a message is retransmitted, the entity that is sending
the message is claiming the presence of the node at 
that instance of time and the timestamp in the message
should reflect that. If the nodes keep retransmitting
for a longer and longer times, we need to consider lot
more cases to handle this correctly. I do not know,
what issues you are Suresh are foreseeing, when a message
is retransmitted with a new timestamp. If there is an
issue that you see, then we can try to fix this logic.

Sri

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Tuesday, September 25, 2007 6:55 PM
> To: Vijay Devarapalli; Suresh Krishnan
> Cc: [email-masked]
> Subject: [netlmm] Issue: Retransmissions and timestamps
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 25 Sep 2007 20:59:59 -0700

Hi Alex,

> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Tuesday, September 25, 2007 5:30 AM
> To: Sri Gundavelli
> Cc: 'Suresh Krishnan'; [email-masked]
> Subject: Re: DHCP Relay link-address use is probably 
> inapppropriate (was: [netlmm] Suresh's review of 
> draft-ietf-netlmm-proxymip6-05)
> 
> Sri Gundavelli wrote:
> [...]

Yes. I agree. I used to say, "prefix pool hint". Its the address
on the interface of the AR that is hosting the prefix. You are
right. Lets take Cafe::/64 as the pool. The AR has Cafe::1 on the
interface, the DHCP server will allocate an address from the pool
"cafe". Thats all to this dhcp based address configuration.

I think, once an IPv6 link is configured and is up, all the IPv6
properties on that link should survive. It should not matter if 
the link is configured dynamically or statically. Its very important
that we dont see the MN-AR link as a special link. The MAG vendors
should have the ability to drop in features, say, Firewall, Access
Security protocols ... or what ever services that are built for an
IPv6 access link. This is a design goal, IMHO.

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 25 Sep 2007 21:07:24 -0700

Hi Suresh,

Please see inline.

Regards
Sri

> Sent: Tuesday, September 25, 2007 7:19 AM
> To: Sri Gundavelli
> Cc: [email-masked]

Ok.

> MAGs and the LMAs becomes a big issue.

Lets discuss this timestamp related issue offline. Need be,
lets have a conf call between the main contributors to this
section and close this in the right way. 

> a checking step in the LMA operation will do.

Ok. Will make it explicit.

> the timer to this case. Can you please clarify.

No, its for the other case. If the dereg msg from the old MAG 
arrives at the LMA before the reg msg from the new MAG arrives,
we dont want to delete the binding, but wait and see if there
will be an reg BU from a new BU. Why timer ? What if the MN
roams away ? We need to give enough time for the MN to roam
to a new link, atleast wait till that time and later remove
the BCE.

> retransmitted it

Ok. We will discuss this timestamp issues in conf call.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 26 Sep 2007 11:39:45 +0200

Sri, more details below.

In short: (1) I know three DHCPv6 implementations that don't use your
'link-address' recommendation; two of them use the Interface ID instead.
(2) which implementation of 'link-address' field are you talking about?
(3) logically speaking, in order to make your intention work (use
'link-address' as the prefix of the ptp link MN-AR) we need a prefix
field next to the 'link-address' field in RELAY-FORWARD, otherwise it
can't work; (4) how can every MAG make sure it has Cafe::1/64 on its own 
virtual interface whenever that certain MN attaches to it?

So I don't think we should write the recommendation of 'link-address' in
DHCP RELAY-FORWARD.

Sri Gundavelli wrote:
> Hi Alex,
> 
> 
> 
>> -----Original Message----- From: Alexandru Petrescu 
>> [mailto:[email-masked]] Sent: Tuesday, September 25, 
>> 2007 5:30 AM To: Sri Gundavelli Cc: 'Suresh Krishnan'; 
>> [email-masked] Subject: Re: DHCP Relay link-address use is 
>> probably inapppropriate (was: [netlmm] Suresh's review of 
>> Sri Gundavelli wrote: [...]
>>>> link-address field of the DHCP relay message since the 
>>>> link-address field does not contain a prefix length. Is there 
>>>> an implicit assumption that the prefix will be 64 bits in 
>>>> length?
>>>> 
>>> If the relay agent received the message to be relayed from a 
>>> client, the relay agent places a global or site-scoped address 
>>> with a prefix assigned to the link on which the client should be
>>> assigned an address in the link-address field.
>> I think it wrongly says "with a prefix".  Because: (1) it makes 
>> people think there is a prefix length in that field, (2) the DHCP 
>> RELAY-FORWARD doesn't encode a prefix length (3315 pp 18) (3) 
>> wireshark doesn't show a prefix length field, (4) Dibbler 
>> implementation doesn't encode a prefix length but a full /128 
>> address in that field, it's the address of the Relay interface on 
>> which a mobile attaches.
>> 
> 
> Yes. I agree. I used to say, "prefix pool hint". Its the address on 
> the interface of the AR that is hosting the prefix. You are right. 
> Lets take Cafe::/64 as the pool. The AR has Cafe::1 on the interface,
>  the DHCP server will allocate an address from the pool "cafe". Thats
>  all to this dhcp based address configuration.

This is DHCPv4 (not DHCPv6) implementation.  And, this assumes that 
_any_ Relay to which MN will attach will have configured the Cafe::1/64 
address on its (virtual) interface.  Otherwise DHCP can't deliver same 
home address to MN wherever it attaches.  How does the Relay always 
obtains that Cafe::1/64 for its interface when that particular MN 
attaches to it?

> properties on that link should survive. It should not matter if the 
> link is configured dynamically or statically.

I think I agree in general on this, for DHCPv4.  If the MN-AR is a 
virtual interface and is put up dynamically at MAG/DHCP Relay, then the 
prefix and address configured on it and the address is taken by the 
Relay and sent to the Server in the 'link-address' field.

What you're saying (IP link up and configured conserves all IP
properties) is true for a DHCP _v4_ configuration, not DHCPv6.  Running
DHCPv4 Relay on a wifi link, and having configured that link with a
certain prefix (/24 or other) makes the Server assign an address to that
node within that prefix, because the server has the prefix configured in
its configuration file (the 'subnet' in the config file).  It is
sufficient for the Relay to put the DHCP Relay's address in the
'link-address' field of the RELAY-FORW, and the Server will match that
to the 'subnet' from config file, in order to assign an address from the
pool defined within that subnet.  That is ok.

However, with DHCPv6 the story is different.  ISC DHCP alpha most recent
implementation has an equivalent 'subnet6' clause at server but no Relay
  implementation, unfortunately.  Its 'subnet6' works only when the
Server is located on the MAG (and you seem to oppose that).  When and
how a Relay is available and how it will work is speculation.

Dibbler and WIDE DHCP Server and Relay implementations Servers'
configuration files don't have this 'subnet' nor 'subnet6' fields.  They
do have Relay implementations and they can have prefixes on Relay
interfaces, but the allocation is done by using a Interface ID in the
RELAY-FORWARD message, and the 'link-address field' is not used.
Basically the Server's configuration file configures interface id '1'
for a Relay's interface that the Relay also calls '1'; this
configuration is consistent across all Relays and the Server, and a
unique IPv6 address is assigned according to this interface id.

> Its very important that we dont see the MN-AR link as a special link.
>  The MAG vendors should have the ability to drop in features, say, 
> Firewall, Access Security protocols ... or what ever services that 
> are built for an IPv6 access link. This is a design goal, IMHO.

I fully agree it is important we don't see the MN-AR link as any special
link.

I am not sure about which MAG vendors you talk about and about which
implementations.

If you take the three implementations I've described above - none
follows your suggestion.  One (ISC) _may_ in the future but the other
two don't and don't even need, because they use Interface ID instead of
'link address'.

So I am not sure why insisting with the recommendation to use
'link-address' field when existing DHCPv6 implementations don't use it.

Alex
PS: why do we need a prefix length field next to the 'link-address'
field in DHCP RELAY-FORW in order to make this work?  It's simple,
because the Server needs to match the first _n_ common bits of the
Relay's address and _n_ bits of the address configured in the Server's
config file ('subnet6').  Makes no sense to longest prefix match _n_
bits from the 'subnet6' with an Relay's 'link-addresss having no prefix:
this can easily lead to confusion in deployment.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 26 Sep 2007 09:16:29 -0500

Hi Suresh,

My apologies for not replying earlier.

I believe both scenarios that you proposed need a very special
circumstances in order for them to happen. It will be a good idea to
describe the reality of these scenarios, basically the MN moves quickly
between three different MAGs within a second or so. IMO, it is not worth
addressing scenarios that, in real deployment, will never happen.

One more thing I would like to add here, this case is not specific to
timestamp.

BTW: IMO, The proposed solution still works but probably no point of
going through the details before realizing the reality of these
scenarios. One more thing that I suggested earlier to Kilian and I think
it was also proposed by Vijay is the use of binding revocation. 

But let us understand the reality first. I hope you do not mind. 

Best Regards,
Ahmad

> Sent: Tuesday, September 25, 2007 2:52 PM
> Thanks a lot for doing this. It makes the discussion easier 
> and more productive.
> 
> > 
> > 1. M1: MAG2 sends PBU with Timestamp T (This is lost) [Ahmad] Ok.
> > 
> > updates the binding cache on the LMA) [Ahmad] i. Since LMA did not 
> > receive M1, M2 is considered a handoff from MAG1 to MAG3. right?
> > iv. MAG2 receives P-BA3 with code "MN-handoff-in-progress" and 
> > realizes that the MN is possibly no longer attached to it.
> > 
> Yes, I do see a problem. How do you differentiate the two 
> following cases with the solution you proposed
>

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 26 Sep 2007 11:33:02 -0400

Hi Ahmad,

> My apologies for not replying earlier.

No problems.

> addressing scenarios that, in real deployment, will never happen.

I am not sure what you mean here. I only proposed one scenario, and it 
does not require sub second handovers as a precondition. As long as a 
retransmission happens after a handover, the scenario will come into play.

> it was also proposed by Vijay is the use of binding revocation. 

I will not repeat myself, but the proposed solution does not work, as I 
detailed in my previous mail (text attached to the end of this mail)

> But let us understand the reality first. I hope you do not mind. 

I certainly don't mind.

Thanks
Suresh

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 26 Sep 2007 11:31:12 -0700

I am then confused by the need for a change in timestamp values for
retransmissions.  I was going by the following from Vijay's response to
Suresh: 

"> No. It should always use the latest timestamp value. Otherwise the
LMA 
> re-transmitted from a replayed proxy BU."

The text above seems to imply that for sake of detecting a replayed PBU,
we need to increment timestamps. I was saying that the retransmitted PBU
will have passed IPsec replay protection, while a replayed PBU wouldn't
have.  So, they are distinguishable. 

If IPsec is not used as the security mechanism, the alternate security
mechanism that is used must provide its own replay protection.  It
doesn't seem to make sense to rely on PMIP6 to do replay checks
sometimes and rely on the security protocol for the same at other times.

There is value in doing retransmissions without altering the packet.
Given the above, is there still a reason why the timestamps should be
changed for a retransmitted PBU? 

Thanks,
Vidya

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Tuesday, September 25, 2007 7:18 PM
> To: Narayanan, Vidya; 'Vijay Devarapalli'; 'Suresh Krishnan'
> Cc: [email-masked]
> Subject: RE: [netlmm] Issue: Retransmissions and timestamps
> 
> We are not using timestamps for replay protection. When a 
> message is retransmitted, the entity that is sending the 
> message is claiming the presence of the node at that instance 
> of time and the timestamp in the message should reflect that. 
> If the nodes keep retransmitting for a longer and longer 
> times, we need to consider lot more cases to handle this 
> correctly. I do not know, what issues you are Suresh are 
> foreseeing, when a message is retransmitted with a new 
> timestamp. If there is an issue that you see, then we can try 
> to fix this logic.
> 
> Sri
> 
> 
> 
> 
>  
> 
> > I have a meta question here.  Replay protection is provided using 
> > IPsec, not using timestamps.  Timestamps are meant for ordering the 
> > PBUs and for that purpose, it really appears to me that 
> retransmitted 
> > PBUs need not change the timestamps.  As I mentioned in my review, 
> > that is desirable from a security perspective.  Even from 
> an ordering 
> > timestamp value?  Vijay pointed to replay protection and I 
> claim that 
> > is not needed.  Were there other points?
> > 
> > Thanks,
> > Vidya
> > 
> > > >>> Section 6.9.3
> > > >>> =============
> > > IMO, using the registration revocation mechanism for 
> PMIPv6 might be 
> > > the cleanest approach. Any loss of connectivity is likely to be 
> > > temporary once we have the registration revocation mechanism for 
> > > PMIPv6.
> > > 
> > > Vijay
> > >

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 26 Sep 2007 11:34:10 -0700 (PDT)

We are not using timestamps for replay protection.

I responded to this yesterday, please comment on this.

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 26 Sep 2007 17:45:20 -0700

> Sent: Wednesday, September 26, 2007 11:34 AM
> To: Narayanan, Vidya
> Cc: Vijay Devarapalli; Suresh Krishnan; [email-masked]
> message is 
> >> retransmitted, the entity that is sending the message is 
> claiming the 
> >> presence of the node at that instance of time and the timestamp in 
> >> the message should reflect that.
> >> If the nodes keep retransmitting for a longer and longer times, we 
> >> need to consider lot more cases to handle this correctly. 

I don't understand what the above means.  We need to specify a maximum
retransmission value and the LMA should not be responding to
retransmissions beyond that.  Can you elaborate on what complications
retransmissions with the same timestamp value leads to?  In fact, to the
contrary, if the LMA could never tell the difference between a
retransmission and a new PBU, it will continue to process and respond to
each one.  That seems less desirable to me.  What am I missing? 

Vidya

> I do not 
> >> know, what issues you are Suresh are foreseeing, when a message is 
> >> retransmitted with a new timestamp. If there is an issue that you 
> >> see, then we can try to fix this logic.
> >>
> 
> Sri
> 
> 
> > retransmissions.  I was going by the following from Vijay's 
> response 
> > to
> > Suresh:
> >
> > The text above seems to imply that for sake of detecting a replayed 
> > PBU, we need to increment timestamps. I was saying that the 
> > retransmitted PBU will have passed IPsec replay protection, while a 
> > replayed PBU wouldn't have.  So, they are distinguishable.
> >
> message is 
> >> retransmitted, the entity that is sending the message is 
> claiming the 
> >> presence of the node at that instance of time and the timestamp in 
> >> the message should reflect that.
> >> If the nodes keep retransmitting for a longer and longer times, we 
> >> need to consider lot more cases to handle this correctly. I do not 
> >> know, what issues you are Suresh are foreseeing, when a message is 
> >> retransmitted with a new timestamp. If there is an issue that you 
> >> see, then we can try to fix this logic.
> >>
> >> Sri
> >>
> >>
> >>
> >>
> >>
> >>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 26 Sep 2007 18:29:34 -0700

> each one.  That seems less desirable to me.  What am I missing? 

What is not clear to you from the below quoted text. Let me try
again.

1. What is the intended purpose of the time stamp ? To ensure
   ordering of the messages. A node generating the message adds
   the timestamp. It claims the node is present at that instance
   of time. Dont you think, if we use the same timestamp in the
   retransmissions, will that not beat the purpose ?

2. You should explain, rather than dodging the question, what
   is wrong in the current scheme. If there is an issue, we will
   be glad to change it. As we worked with Kilian, Ahmad, Federico
   and evolved this logic.

3. When using sequence numbers, 3775 does not use the same
   sequence number in retransmitted messages. Why ? This scheme
   is consistent with 3775.
   
   "Retransmitted Binding Updates MUST use a Sequence Number value
   greater than that used for the previous transmission of this Binding
   Update.  Retransmitted Home Test Init and Care-of Test Init messages
   MUST use new cookie values."

4. I do not see a need for the LMA to differentiate between the two.
   The lifetime that it allocates to the session is w.r.t the newly
   received message.

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 26 Sep 2007 23:48:37 -0700

Hi Sri, 

> Sent: Wednesday, September 26, 2007 6:30 PM
> To: Narayanan, Vidya
> Cc: 'Vijay Devarapalli'; 'Suresh Krishnan'; [email-masked]
> > retransmissions with the same timestamp value leads to?  In 
> fact, to 
> > the contrary, if the LMA could never tell the difference between a 
> > retransmission and a new PBU, it will continue to process 
> and respond 
> > to each one.  That seems less desirable to me.  What am I missing?
> > 
> 
> 

Not really.  A retransmission says that the MAG notified that the MN is
present earlier, but, it hasn't heard an ack yet. 

>    be glad to change it. As we worked with Kilian, Ahmad, Federico

I did explain in my review - basically, retransmissions are efficiently
done by simply caching the constructed message until a response is
received and sending it again if no response was received within a given
time.  It also helps the LMA, since the LMA can cache the responses for
a short amount of time to simply re-send it upon receiving a
retransmitted PBU.  This is a commonly used philosophy to mitigate the
impact of DoS attacks also - i.e., the idempotent nature of an entity
involves less work than processing and responding to each message as if
it was a new one.  It also helps the LMA to stop responding after a few
retransmissions have been responded to.  So, I think that unless there
is a good reason to increment the timestamps for retransmissions, it
shouldn't be.  

I'll let Suresh outline the issue he was describing.  

Thanks,
Vidya

---

From: Julien Laganier <[email-masked]>
Date: Thu, 27 Sep 2007 14:14:33 +0200

On Tuesday 25 September 2007, Suresh Krishnan wrote:
> routers to the new MAG. The link local addresses of the old MAG and
> the new MAG will most likely be different and hence unless nud
> removes the old mag the mn will try to reach it even after handover.
> Or it is assumed that all the MAGs will have the same LL address? Is
> this is an assumption, it needs to be stated.

FWIW the current DNAv6 spec would not require NUD to kick in and remove 
the old MAG. The MN would simply select a new router that is in 
reachable state. From [I-D.ietf-dna-protocol-06]:

5.2.6.3  Router Reachability Detection and Default Router Selection

[...]

   Prior to sending a DNA RS in response to an indication of link
   change, the host SHOULD set all Neighbor Cache entries for routers on
   its Default Router List to STALE.  When the host receives an RA in
   reply to the RS, the host SHOULD mark that router's Neighbor Cache
   Entry [3] as REACHABLE, or add a Neighbor Cache Entry in the
   REACHABLE state if one does not currently exist.

   The host SHOULD also update its Default Router List in the following
   fashion.  If any of the routers returning RAs are already on the
   default router list, the host SHOULD use the information in the RA to
   update the Default Route List entry with the new information.  The
   host SHOULD add entries to the Default Router List for any routers
   returning RAs that are not on the list.  The host SHOULD confine
   selection of a router from the Default Router List to those routers
   whose Neighbor Cache entries are in the REACHABLE state.  Note that
   the Default Router List SHOULD be updated as described here
   regardless of whether the RA indicates that the host has changed to a
   new IP link, since changes in router reachability are possible on
   some link types even if the host remains on the same IP link.

--julien

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 27 Sep 2007 07:19:32 -0700

Hi Julien,

> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Thursday, September 27, 2007 5:15 AM
> To: [email-masked]
> Subject: Default router and new MAG (Was: [netlmm] Suresh's 
> review ofdraft-ietf-netlmm-proxymip6-05)
> 

Thanks. This is very important. I can add a reference to this.
Probably, a good reason to enable to DNAv6 on the MN.

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 27 Sep 2007 12:33:37 -0500

Sri,

> Probably, a good reason to enable to DNAv6 on the MN.

We cannot be having any requirements on the MN. So lets not start saying
that the MN should enable DNAv6 or expect it to do anything new for it to
work in a PMIP domain.

-Raj

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 27 Sep 2007 10:41:08 -0700

Raj, 

> that the MN should enable DNAv6 or expect it to do anything 

We are not mandating DNAv6. Its informational. If MN has DNAv6
stack, it can flush the old AR entry immediatly. That is very
important. Do you see any issue, stating that point ? 

Sri

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Thu, 27 Sep 2007 20:01:42 +0200

Hi Vidya,

I think you and Sri are talking about different re-transmissions
You're talking about the retransmission of a PBU in case the previous PBU or the previous PBack was lost
Sri is talking about the retransmission of a PBU when the MAG receives a TIMESTAMP_MISTMACH error code

Citing v6 of the I-D:
"If the received Proxy Binding Acknowledgement message has the Status field value set to TIMESTAMP_MISMATCH (Invalid Timestamp), the mobile access gateway SHOULD try to register again only after it has synchronized its clock to a common time source that is used by all the mobility entities in that domain for their clock synchronization. "

Regards

federico

-----Message d'origine-----
De : Narayanan, Vidya [mailto:[email-masked]] 
Envoyé : jeudi 27 septembre 2007 08:49
À : Sri Gundavelli
Cc : [email-masked]
Objet : RE: [netlmm] Issue: Retransmissions and timestamps

Hi Sri, 

> What is not clear to you from the below quoted text. Let me try again.
> 

Not really.  A retransmission says that the MAG notified that the MN is present earlier, but, it hasn't heard an ack yet. 

>    be glad to change it. As we worked with Kilian, Ahmad, Federico

I did explain in my review - basically, retransmissions are efficiently done by simply caching the constructed message until a response is received and sending it again if no response was received within a given time.  It also helps the LMA, since the LMA can cache the responses for a short amount of time to simply re-send it upon receiving a retransmitted PBU.  This is a commonly used philosophy to mitigate the impact of DoS attacks also - i.e., the idempotent nature of an entity involves less work than processing and responding to each message as if it was a new one.  It also helps the LMA to stop responding after a few retransmissions have been responded to.  So, I think that unless there is a good reason to increment the timestamps for retransmissions, it shouldn't be.  

Thanks,
Vidya

> >> We are not using timestamps for replay protection. When a message 
> >> is retransmitted, the entity that is sending the message is 
> >> claiming the presence of the node at that instance of time and the 
> >> timestamp in the message should reflect that.

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Fri, 28 Sep 2007 15:44:20 +0200

Hi Sri,

Sri> If MN has DNAv6 stack, it can flush the old AR entry immediately. That is very important.
[FDJ] Can you clarify why is it "very important"?

The above problem statement talks about LLAs and the title of the thread talks about default routers
Is there a link between the two?

When the link model is point-to-point I presume that it is useless to keep track of the default router
Even if the host was keeping track of the default router, I presume that this should be per link, and since the link changed, the host should be capable of handling it autonomously

What the LLA concernFrom [email-masked] Fri Sep 28 09:45:00 2007
Content-class: urn:content-classes:message
Subject: RE: Default router and new MAG (Was: [netlmm] Suresh's
	reviewofdraft-ietf-netlmm-proxymip6-05)
Date: Fri, 28 Sep 2007 15:44:20 +0200
From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
To: "Sri Gundavelli" <[email-masked]>
Cc: [email-masked], Julien Laganier <[email-masked]>

Hi Sri,

Sri> If MN has DNAv6 stack, it can flush the old AR entry immediately. That is very important.
[FDJ] Can you clarify why is it "very important"?

The above problem statement talks about LLAs and the title of the thread talks about default routers
Is there a link between the two?

When the link model is point-to-point I presume that it is useless to keep track of the default router
Even if the host was keeping track of the default router, I presume that this should be per link, and since the link changed, the host should be capable of handling it autonomously

What the LLA concerns, I guess that the LLA of the old MAG will eventually go stale
Is the MAG LLA actually relevant for the host?

Regards

federico

-----Message d'origine-----
De : Sri Gundavelli [mailto:[email-masked]] 
Envoyé : jeudi 27 septembre 2007 19:41
À : 'Basavaraj Patil'; 'Julien Laganier'; [email-masked]
Objet : RE: Default router and new MAG (Was: [netlmm] Suresh's reviewofdraft-ietf-netlmm-proxymip6-05)

Raj, 

> We cannot be having any requirements on the MN. So lets not start 
> saying that the MN should enable DNAv6 or expect it to do anything new 
> for it to work in a PMIP domain.
> 

We are not mandating DNAv6. Its informational. If MN has DNAv6 stack, it can flush the old AR entry immediatly. That is very important. Do you see any issue, stating that point ? 

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Sun, 30 Sep 2007 17:41:02 -0500

> important. Do you see any issue, stating that point ?

Nope... Its fine to mention it as long as it is not required or mandated.

-Raj