Subject: [Mip6] New charter item: HA assignment

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 18 Jul 2006 13:31:18 +0200

Hi,

as promised during the mip6 session, here is a point which, IMO, is
important from a MSP's point of view:
Actually, the bootstrapping solution, in the split scenario, only
propose a HA discovery mechanism (i.e. the MN receives a list of HA,
from DNS, and chooses one of them). The MSP has no easy solution to
enforce one MN to have a specific HA.

Best regards.

JMC.

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Jul 2006 18:49:09 +0200

Jean-Michel Combes wrote:
> important from a MSP's point of view: Actually, the bootstrapping 
> solution, in the split scenario, only propose a HA discovery 
> mechanism (i.e. the MN receives a list of HA, from DNS, and chooses 
> one of them). The MSP has no easy solution to enforce one MN to have 
> a specific HA.

One possible way is for a HA to stop sending BAck, at which point an MN
would send DHAAD Request again, and a different HA replies back DHAAD,
so end result is MN is assigned a new HA.

Another way is for the new HA to send Binding Refresh Request to MN
(even if it has no BC entry for it).

Another way, if the split bootstrapping advances, is for the MSP to
dynamically update the DNS data about HAs, so when MN bootstraps it
obtains a different HA.

If the HA address is discovered with DHCP then I think the DHCP Server
can send specific messages to MN (unsolicited by MN).

It would require relaxing some language in rfc 3775 and probably 
extending BRR.

It would be helpful to know when would an MSP like the MN to choose a
different HA, for what reasons.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Jul 2006 11:30:33 -0700

> enforce one MN to have a specific HA.

do you want an entity in the MSP to assign the HA
to the MN?

we can come up with some hacks to the HA discovery
mechanism to force the MN to pick a particular HA,
but I would rather avoid it. it would be better if
you tell us what the scenario and which are the
entities involved. then we can design a solution
for the specific scenario.

another option is to use HA Switch mechanism described
in http://www.ietf.org/internet-drafts/draft-ietf-mip6-ha-switch-00.txt

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Jul 2006 11:42:06 -0700

So there are three ways I can think of that one could go about assigning an 
HA.

1) The MN uses the weights returned with the DNS SRV record from RFC 2782 to 
guide its selection of HAs. Less preferred HAs are later in the preference 
ordering. The authors of RFC 2782 complain about weights being a relatively 
coarse-grained mechanism that isn't up to providing dynamic load balancing. 
I think the time granularity of the SRV updates would  be about 15 seconds 
minimum, if dynamic DNS is used, since I'm told that is about the amount of 
time one should expect it to take for a dynamic DNS update to propagate.

2) For a more dynamic mechanism, the HA initially tried by the MN can turn 
down the MN's request to perform IKEv2. Or the HA could deny the MN an HoA. 
This would cause the MN to roll over to the next HA on the list. When the MN 
hit the right HA, the IKEv2 transaction would succeed. This has the 
disadvantage that it increases the amount of time the MN needs to bootstrap.

3) Immediately after the MN finishes the IKEv2 transaction, the first HA 
could send a HA Switch message (draft-ietf-mip6-ha-switch-00.txt) within the 
IPsec SA, telling the MN to go elsewhere. The MN would be delayed  by the 
amount of time needed to do the IKEv2 transaction, but that does provide 
security. This seems like it would be the most direct way.

I think a combination of these three mechanisms would be sufficient to 
provide HA assignment for the kinds of deployment scenerios that the split 
scenerio was designed to accommodate. The first mechanism would provide load 
balancing over longer periods while the second would provide support for 
fast transients, and the third would provide a way to directly and securely 
tell an MN where to go. Ideally, the MN wouldn't have to go through more 
than one additional HA before it got service, reducing the amount of lag.

On the other hand, if you want a way to say "thou shalt use this HA" without 
a lot of initial negotiation, then I'd suggest using the intergrated 
scenerio and simply let DHCP assign the MN to an HA (though that would 
require DHCP security).

If these are insufficient, then the only other suggestion is that an IKEv2 
INFORMATIONAL message be defined directing the MN to try IKEv2 with another 
node (which would be the preferred HA). Such a message could be used for VPN 
server load balancing too.

            jak

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "Jean-Michel Combes" <[email-masked]>
Cc: "Mobile IPv6 Mailing List" <[email-masked]>
Sent: Tuesday, July 18, 2006 9:49 AM
Subject: Re: [Mip6] New charter item: HA assignment

>> solution, in the split scenario, only propose a HA discovery mechanism 
>> (i.e. the MN receives a list of HA, from DNS, and chooses one of them). 
>> The MSP has no easy solution to enforce one MN to have a specific HA.
>
> It would require relaxing some language in rfc 3775 and probably extending 
> BRR.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Jul 2006 21:31:05 +0200

James Kempf wrote:
> So there are three ways I can think of that one could go about 
> assigning an HA.
> 
> 1) The MN uses the weights returned with the DNS SRV record from RFC 
> 2782 to guide its selection of HAs. Less preferred HAs are later in 
> the preference ordering. The authors of RFC 2782 complain about 
> weights being a relatively coarse-grained mechanism that isn't up to 
> providing dynamic load balancing. I think the time granularity of the
>  SRV updates would  be about 15 seconds minimum, if dynamic DNS is 
> used, since I'm told that is about the amount of time one should 
> expect it to take for a dynamic DNS update to propagate.

I agree that 15 seconds is more on the lower boundary...  On Internet it
can take days.

Within one operator's network it could be much lower though.

> 2) For a more dynamic mechanism, the HA initially tried by the MN can
>  turn down the MN's request to perform IKEv2. Or the HA could deny 
> the MN an HoA. This would cause the MN to roll over to the next HA on
>  the list. When the MN hit the right HA, the IKEv2 transaction would 
> succeed. This has the disadvantage that it increases the amount of 
> time the MN needs to bootstrap.
> 
> 3) Immediately after the MN finishes the IKEv2 transaction, the first
>  HA could send a HA Switch message (draft-ietf-mip6-ha-switch-00.txt)
>  within the IPsec SA, telling the MN to go elsewhere. The MN would be
>  delayed by the amount of time needed to do the IKEv2 transaction,
> but that does provide security. This seems like it would be the most 
> direct way.

What if the HA Switch message gets lost?  That's not a TCP message I
suppose.  I haven't read the HA switch draft in detail... is there
retransmission of it?  Is it needed?

Alex

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Jul 2006 12:38:19 -0700

> retransmission of it?  Is it needed?

Like any MIP message, it doesn't use reliable transport. Perhaps we need to 
define retransmission, or require retransmission as defined by RFC 3775.

            jak

---

From: Brian Haley <[email-masked]>
Date: Tue, 18 Jul 2006 15:46:46 -0400

Didn't want to hijack the thread, but wanted to respond to Alex's 
comment below.

Alexandru Petrescu wrote:
>> (i.e. the MN receives a list of HA, from DNS, and chooses one of 
>> them). The MSP has no easy solution to enforce one MN to have a 
>> specific HA.
> 

BRR is sent from CN to MN, it is not defined to be sent from HA.  I know 
you brought-up extending it at the WG meeting (instead of using HA 
switch), but I couldn't remember all the reasons we didn't do that. 
IPsec is the other problem since the message has no protection, but 
needs it.

-Brian

---

From: Brian Haley <[email-masked]>
Date: Tue, 18 Jul 2006 16:55:52 -0400

> retransmission of it?  Is it needed?

Section 4.2 covers retransmissions.  The HA knows the MN got the message 
once it deletes its binding.

-Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 19 Jul 2006 00:04:26 +0200

Brian Haley wrote:
>>> as promised during the mip6 session, here is a point which, IMO,
>>>  is important from a MSP's point of view: Actually, the 
>>> bootstrapping solution, in the split scenario, only propose a HA
>>>  discovery mechanism (i.e. the MN receives a list of HA, from
>>> DNS, and chooses one of them). The MSP has no easy solution to 
>> One possible way is for a HA to stop sending BAck, at which point 
>> an MN would send DHAAD Request again, and a different HA replies 
>> back DHAAD, so end result is MN is assigned a new HA.
>> 
> BRR is sent from CN to MN, it is not defined to be sent from HA.

I think that depends on each one's interpretation of "correspondent".  I
see BRR very well sent by HA to MN if BCE lifetime expired and BU was lost.

> I know you brought-up extending it at the WG meeting (instead of 
> using HA switch), but I couldn't remember all the reasons we didn't 
> do that. IPsec is the other problem since the message has no 
> protection, but needs it.

Mostly ok with that, but I can't completely agree until I haven't read
the draft.  BRR is a Mobility Header, so assumed to be ok with IPsec.

IPsec is anyways a sensitive issue because we're talking three parties:
two HAs (an initial and an "assigned") and one MN, presumably HAs
exchange SAs.  Do you use the CA concept?

I'll have to read it.

Alex

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 18 Jul 2006 15:48:57 -0700

Hi JMC,

In the split scenario, DHCP can be used for HA assignment when the ASP and
the MSP are the same. 

Alper

> -----Original Message-----
> From: Jean-Michel Combes [mailto:[email-masked]]
> Sent: Tuesday, July 18, 2006 4:31 AM
> To: Mobile IPv6 Mailing List
> Subject: [Mip6] New charter item: HA assignment
> 
> Hi,
>

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 19 Jul 2006 10:14:38 +0200

Another possible solution is described in
draft-dupont-ikev2-haassign-01.txt. The MN sends the IKE_SA_INIT to an
anycast HA address and let the anycast receiver forward the message to
the "best" HA. In this case, the "best" HA may be different for every MN
and would be selected based on the source address of the IKE_SA_INIT.

-Kilian

> From: James Kempf [mailto:[email-masked]] 
> Sent: Dienstag, 18. Juli 2006 20:42
> To: Alexandru Petrescu; Jean-Michel Combes
> Cc: Mobile IPv6 Mailing List
> could send a HA Switch message 
> (draft-ietf-mip6-ha-switch-00.txt) within the

---

From: Brian Haley <[email-masked]>
Date: Wed, 19 Jul 2006 12:09:55 -0400

> see BRR very well sent by HA to MN if BCE lifetime expired and BU was lost.

I don't know how you can interpret 3775 (or implement it) such that a HA 
can be a CN of the same MN at the same time.  You're the HA or you 
aren't, and HAs don't send BRRs - TAHI would have a test for it if they 
could :)

>> I know you brought-up extending it at the WG meeting (instead of using 
>> HA switch), but I couldn't remember all the reasons we didn't do that. 

But 3776 doesn't define the use of IPsec for a BRR.

> exchange SAs.  Do you use the CA concept?

CA == ??

> I'll have to read it.

Please do, I'd appreciate any comments.

-Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 19 Jul 2006 19:46:53 +0200

Brian Haley wrote:
> 
>>>> Another way is for the new HA to send Binding Refresh Request 
>>>> to MN (even if it has no BC entry for it).
>>> 
>> I think that depends on each one's interpretation of 
>> "correspondent".  I see BRR very well sent by HA to MN if BCE 
>> lifetime expired and BU was lost.
> 
> I don't know how you can interpret 3775 (or implement it) such that a
>  HA can be a CN of the same MN at the same time.

I don't see the problem with that.

For some implementations it is useful/easy to have HA send BRR to MN.
In this way MN does not need to implement additional timer of receiving
BAck, only a timer for re-transmitting BU and to respond to BRR.

Wrt to how to read rfc3775 and think that CN can be a HA, this is an
exercise indeed, but I'm tempted to do it because I also had
to do it when thinking CN can be a MN.  And, if one thinks NEMOv6 then,
and MN is a MR and MR can be a HA for mobiles in its moving network...
CN can be a HA.

In the end, the BRR message should be implemented as send and receive in
any entity running Mobile IPv6: CN, HA, MH, MR.

Take this 3775 text:
> If the sender knows that the Binding Cache entry is still in active 
> use, it MAY send a Binding Refresh Request message to the mobile node
>  in an attempt to avoid this overhead and latency due to deleting and
>  recreating the Binding Cache entry.

What "sender" maintains a Binding Cache?  Both CN and HA, only MN
doesn't.  So MN would not send BRR.  But if MN is a CN to another MN
then MN would send BRR too.

Take this other 3775 text:
> This message [BRR] is always sent to the home address of the mobile 
> node.

So HA sends BRR to the HoA, HA (same entity) intercepts it because proxy
ND for HoA, and encapsulates and sends it to CoA.

> You're the HA or you aren't, and HAs don't send BRRs - TAHI would 
> have a test for it if they could :)

I suppose TAHI's interpretation of 3775 is that HA doesn't send BRRs.
Some implementations don't conform to TAHI then.

>>>  using HA switch), but I couldn't remember all the reasons we 
>>> didn't do that. IPsec is the other problem since the message has
>>>  no protection, but needs it.
>> 
>> Mostly ok with that, but I can't completely agree until I haven't 
>> read the draft.  BRR is a Mobility Header, so assumed to be ok with
>>  IPsec.
> 

Indeed, it hasn't text about BRR and IPsec.  But BRR is like a BAck
isn't it?  They use the same SA, so same IPsec processing rules would
apply, no?

>> IPsec is anyways a sensitive issue because we're talking three 
>> parties: two HAs (an initial and an "assigned") and one MN, 
>> presumably HAs exchange SAs.  Do you use the CA concept?
> 
> CA == ??

(Cert Authority...)

Remark also that BRR has currently no content, but is extensible to have
new mobility options, so one may wonder why was it made extensible.

Anyways, any other opinion on whether HA should send BRR or not is
useful to the discussion.

And you're right that it could be that BRR is sent only by CN.

> Please do, I'd appreciate any comments.

I'll have to read in detail.

For ha-switch:
-the content of ha-switch is same as DHAAD Reply.  While DHAAD Req
  arguably has anycast IPsec issues, DHAAD Reply doesn't.
-sec considerations section does not ack that an attacker HA may DoS a
  legitimate HA, both of which have SAs with MN.

For hareliability:
-not sure how HA SA and IPsec state synchronization can happen.
  It's out of scope for this doc - ok, but how can it happen?
-"All the home agents in the redundant home agent set share a virtual
   address and the routing will ensure only the Active Home Agent will be
   reachable using that virtual address." - is this DHAAD?

Just comments, it may be I haven't understood correctly the draft,
I'll read later, thanks,

Alex

---

From: Brian Haley <[email-masked]>
Date: Wed, 19 Jul 2006 16:42:43 -0400

Alex,

> any entity running Mobile IPv6: CN, HA, MH, MR.

I'll agree to disagree.

>>  recreating the Binding Cache entry.

You're taking this out of context, this text was from this section of 3775:

   9. Correspondent Node Operation
   9.5.5.  Sending Binding Refresh Requests

> then MN would send BRR too.

All nodes that implement mobility should have a binding cache, a MN is 
technically a CN.

>> This message [BRR] is always sent to the home address of the mobile node.
> 

You forgot the rest of the section:

    The correspondent node MAY retransmit Binding Refresh Request
    messages as long as the rate limitation is applied.  The
    correspondent node MUST stop retransmitting when it receives a
    Binding Update.

Again, you omitted the CN-specific text.

>> You're the HA or you aren't, and HAs don't send BRRs - TAHI would have 
>> a test for it if they could :)
> 

There are no implementations that conform to your interpretation, at 
least not at any Connectathon or ETSI event I've been to.  I didn't even 
implement BRR in my code since it's optional and mobility can continue 
without it, just not optimized.

> new mobility options, so one may wonder why was it made extensible.

Well, all the mobility headers in 3775 support options (ie no fixed 
Length field), they all just don't have ones defined.

> useful to the discussion.

I will not continue down that rathole, this is the last email...

>  arguably has anycast IPsec issues, DHAAD Reply doesn't.

It is very similar to a DHAAD Reply.

>  legitimate HA, both of which have SAs with MN.

The current ha-switch draft doesn't mention other HAs because the -00 
version has no support for the ha-reliability draft - the HA sending the 
switch must be the MNs current HA.  When we extend it to support it 
we'll add some text.  I would assume that any HA a MN has a security 
relationship with should be trusted enough to not send rogue DoS packets 
to it.

>  It's out of scope for this doc - ok, but how can it happen?

The group of HAs share a trust relationship, maybe one of the other 
authors can answer that question as it's not my strong point.

>   reachable using that virtual address." - is this DHAAD?

No, just a virtual IPv6 address.

If you have comments on the other drafts you should probably start a new 
thread.

-Brian

---

From: "James Kempf" <[email-masked]>
Date: Wed, 19 Jul 2006 14:16:03 -0700

> authors can answer that question as it's not my strong point.

Any "synchronication" would need to be at a pretty gross level. For example, 
all HAs have access to the same AAA backend so that they can authenticate an 
EAPoIPsec transaction. I don't think any attempt to synchronize by having 
the HAs share SA state would be acceptable to the Security Directorate, as 
it would raise an issue of cascading effects if one HA was compromised.

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Jul 2006 15:00:56 +0200

Brian, thanks for the message.

Brian Haley wrote:
> Alex,
> 
>>>>>> Another way is for the new HA to send Binding Refresh 
>>>>>> Request to MN (even if it has no BC entry for it).
>>>>> 
>>> I don't know how you can interpret 3775 (or implement it) such 
>>> that a HA can be a CN of the same MN at the same time.
>> 
>> For some implementations it is useful/easy to have HA send BRR to 
>> MN. In this way MN does not need to implement additional timer of 
>> receiving BAck, only a timer for re-transmitting BU and to respond 
>> to BRR.
>> 
>> Wrt to how to read rfc3775 and think that CN can be a HA, this is 
>> an exercise indeed, but I'm tempted to do it because I also had to 
>> do it when thinking CN can be a MN.  And, if one thinks NEMOv6 
>> then, and MN is a MR and MR can be a HA for mobiles in its moving 
>> network... CN can be a HA.
>> 
>> In the end, the BRR message should be implemented as send and 
>> receive in any entity running Mobile IPv6: CN, HA, MH, MR.
> 
> I'll agree to disagree.
> 
>> Take this 3775 text:
>>> If the sender knows that the Binding Cache entry is still in 
>>> active use, it MAY send a Binding Refresh Request message to the 
>>> mobile node in an attempt to avoid this overhead and latency due 
>>> to deleting and recreating the Binding Cache entry.
> 
> You're taking this out of context,

Brian, I tried to keep quoted text short, it was not my intention to
confuse.  Indeed, most 3775 text about BRR specifically says CN, no BRR
text says HA.  My point was to say that "CN" can be interpreted as "HA".
  I agree we disagree about that.

>> I suppose TAHI's interpretation of 3775 is that HA doesn't send 
>> BRRs. Some implementations don't conform to TAHI then.
> 
> least not at any Connectathon or ETSI event I've been to.

That is a good point to know, informative, thanks.

> I didn't even implement BRR in my code since it's optional and 
> mobility can continue without it, just not optimized.

I have same reasoning about other parts of MIP6.

Alex

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 20 Jul 2006 16:07:46 +0200

Hi Alex,

> so end result is MN is assigned a new HA.

Normally, the DHAAD reply is again a list of HAs.

> (even if it has no BC entry for it).

IIRC, only CNs send BRR to MN. Am I wrong?

> dynamically update the DNS data about HAs, so when MN bootstraps it

Again here, this is a list of HAs.

> can send specific messages to MN (unsolicited by MN).

But, here, you are doing the assumption there is a DHCP Server or
Relay in the Access Network, which is not always the case.

> different HA, for what reasons.

If an operator sets up different types of mobility like MIPv6, HMIPv6,
NEMO or Monami6. I don't think that all the operator's HAs will
support all these services :)

Best regards.

JMC.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Jul 2006 16:48:51 +0200

Jean-Michel Combes wrote:
>>> discovery mechanism (i.e. the MN receives a list of HA, from DNS,
>>> and chooses one of them). The MSP has no easy solution to enforce
>>> one MN to have a specific HA.
>> 

Yes, and the MN can choose the first.  The important thing is when that
list changes.

> IIRC, only CNs send BRR to MN. Am I wrong?

Seems I'm the only one who believes HA can send BRRs.  Another
opinion(s) here agrees with you.

3775 says CN sends BRR and doesn't say HA must not send BRR.

>>  dynamically update the DNS data about HAs, so when MN bootstraps
>> it obtains a different HA.
> 
>> If the HA address is discovered with DHCP then I think the DHCP
>> Server can send specific messages to MN (unsolicited by MN).
> 

Right, depends on the industry needs.

>> It would be helpful to know when would an MSP like the MN to choose
>> a different HA, for what reasons.
> 
> If an operator sets up different types of mobility like MIPv6,
> HMIPv6, NEMO or Monami6. I don't think that all the operator's HAs
> will support all these services :)

So you see an MN initially using a certain MIP6 HA, and then at some
point operator decide that that particular mobile should use a HMIPv6
HA?  What would be the scenario?

Alex

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 20 Jul 2006 18:06:04 +0200

Hi James,

> time one should expect it to take for a dynamic DNS update to propagate.

This is discovery and not assignment. Nothing prevents the MN to
choose the HA it wants.
Another problem is this solution has no granularity: you cannot play
with the weights depending which MN requests the HAs list.

BTW, be careful with the update of the DNS:
- if DNSSEC is used: real-time update not possible
- take account the time the update will be propagated to the secondary
servers/cache DNS

The 2 main reasons I said I didn't like this solution at the beginning
of the discussion about the split scenario draft but this is out of
scope here :)

> disadvantage that it increases the amount of time the MN needs to bootstrap.

That could work but I agree about the increase about the amount of time.

> security. This seems like it would be the most direct way.

Why not.

> scenerio and simply let DHCP assign the MN to an HA (though that would

Yes but we need solutions for all the scenarios. I don't see an
operator sending a message to a mobility subscriber saying "You are
not in an integrated case: please, stop using the IETF network if you
want to bootstrap your IPv6 mobility service" ;)

> server load balancing too.

Maybe too depend to a specific service: I am not sure that IPsec guys
will accept such an addition in IKEv2.

Best regards.

JMC.

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 20 Jul 2006 18:20:36 +0200

Hi Alper,

IMO, this is more a sub-case of the integrated scenario.

Best regards.

JMC.

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 20 Jul 2006 18:25:33 +0200

Hi Kilian,

> and would be selected based on the source address of the IKE_SA_INIT.

This is a possible solution. Now, the problem is what mechanism to use
to forward the message to the "best" HA? Maybe, this is a sub-case of
use for the future HA reliability protocol?

Best regards.

JMC.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 20 Jul 2006 09:48:24 -0700

Jean-Michel,

> want to bootstrap your IPv6 mobility service" ;)

The assumption behind the integrated scenerio is that the operator has 
deployed it and that there is configuration from the operator when the 
terminal first boots up instructing the terminal to henceforth try DHCP for 
HA configuration prior to rolling over to the split scenerio method.

> will accept such an addition in IKEv2.

IPsec WG is no more. Adding INFORMATIONAL messages to IKEv2 is OK, of 
course, it would need to go through SAAG review as with every other security 
item, and they might object.

Anyway, it seems that HA assignment can be done using the HA Switch message 
within the IPsec SA, at some expense to establish the SA with the original 
HA. But I believe that expense would be needed in any case to establish 
security, and it won't be acceptable from a security standpoint to send an 
HA assignment message without security. An IKEv2 message would reduce the 
amount of security configuration slightly, but is it really necessary?

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Jul 2006 10:43:33 -0700

Jean-Michel Combes wrote:

> A MSP wants to assign a specific HA to a specific MN because:
> - the HAs are owned by the MSP (the main reason!!! :)
> - the MN uses a specific mobility mechanism (e.g. MIPv6, HMIPv6, NEMO, 
> Monami6)
> - the operator wants to loadbalance the charge on the different HAs it
> owns during the bootstrapping (e.g to avoid DoS attacks)
> - the operator offers different types of QoS on the HAs

by scenario I meant the specific deployment. it might be
better to handle this deployment specific instead of trying
to design a generic solution.

Vijay

---

From: "Kilian Weniger" <[email-masked]>
Date: Mon, 24 Jul 2006 13:39:23 +0200

Hi James, 

> Sent: Donnerstag, 20. Juli 2006 18:48
> To: Jean-Michel Combes
> Cc: Mobile IPv6 Mailing List; Alexandru Petrescu
> >> On the other hand, if you want a way to say "thou shalt 
> use this HA" 
> >> without
> >> If these are insufficient, then the only other suggestion 
> is that an 
> >> IKEv2
> >> INFORMATIONAL message be defined directing the MN to try 
> IKEv2 with 
> >> another
> >> node (which would be the preferred HA). Such a message 
> could be used for 
> >> VPN

Another drawback of the HA switch solution is that it may not fulfill
one of the requirements stated by Jean-Michel: 
"- the operator wants to loadbalance the charge on the different HAs it
owns during the bootstrapping (e.g to avoid DoS attacks)"

If the initial HA is overloaded (e.g., due to DoS attack) and all new
MNs select the same initial HA within a longer period of time (according
to the weights in DNS), new MNs cannot get mobility service or only
after a timeout when falling back to another HA (and if all MNs fall
back to the same HA, the new HA may be overloaded soon as well). 

However, the problem depends on how the initial HA is selected.
Anycasting can be used to prevent that new MNs select the same initial
HA. For instance, the IKE_SA_INIT can be anycasted. But if this is done,
you can easily get rid of the unnecessary SA establishment and the
switch message by requiring the receiver HA to forward the IKE_SA_INIT
to a MN-specific and low-loaded HA (see
draft-dupont-ikev2-haassign-01.txt for details). 

-Kilian

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Mon, 24 Jul 2006 16:50:31 +0200

Hi Vijay,

sorry but I don't understand your question ...

Why do you need a specific scenario? We have already one: the split
scenario. This is the same but the MSP wants to assign the HA because
of the previous technical reasons I cited.

Best regards.

JMC.

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Jul 2006 10:26:48 -0700

Kilian Weniger wrote:

> HA. For instance, the IKE_SA_INIT can be anycasted. 

is there another instance of using anycast for load balancing.
just curious.

> But if this is done,

how do you do this? you would still need a HA-to-HA protocol to
forward the IKE_SA_INIT message to another HA. when you send a
message to an anycast address routing decides which HA receives
the message.

I have seen anycast used to direct a user to the "nearest" server.
"nearest" means nearest by routing hops. when all the HAs on the
same link, I wonder if anycast gets any load balancing at all.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Jul 2006 11:26:48 -0700

Kilian,

jak>> So what happens if the machine hosting the anycast address is under 
DoS attack?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Jul 2006 11:35:52 -0700

The other problem with this solution is that there is still no secure way 
for a collection of unicast server addresses to get assigned to an anycast 
address, except for static configuration. So how would the operator be able 
to add HAs to the anycast address?

At least, with the DNS solution, the update of the DNS can be automated 
using dynamic DNS.

                        jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Jul 2006 12:08:18 -0700

hi Jim,

I think manual configuration is sufficient in this case. it is
not too often that home agents get added to or deleted from the
the anycast group.

Vijay

James Kempf wrote:
> The other problem with this solution is that there is still no secure 
> way for a collection of unicast server addresses to get assigned to an 
> anycast address, except for static configuration. So how would the 
> operator be able to add HAs to the anycast address?
> 
> ----- Original Message ----- From: "Vijay Devarapalli" 
> <[email-masked]>

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Jul 2006 12:16:46 -0700

I thought the whole point of  the anycast proposal  and Kilian and 
Jean-Marie's argumet against DNS was load balancing and that DNS is 
insufficient because it does not provide fast enough dynamic update. If that 
is the case, then I would think that the ability to quickly add and remove 
addresses from the anycast group would be crucial to removing HAs that are 
loading and adding new ones that aren't.

            jak

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Kilian Weniger" <[email-masked]>; <[email-masked]>
Sent: Monday, July 24, 2006 12:08 PM
Subject: Re: [Mip6] New charter item: HA assignment

>> for a collection of unicast server addresses to get assigned to an

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Jul 2006 12:16:59 -0700

James Kempf wrote:
> insufficient because it does not provide fast enough dynamic update. If 
> that is the case, then I would think that the ability to quickly add and 
> remove addresses from the anycast group would be crucial to removing HAs 
> that are loading and adding new ones that aren't.

load balancing does not necessarily mean removing/adding a HA
from/to the list of HAs. I think it is more about directing the
users to the right HA. you can have a pretty stable anycast
group and still direct the MN to a specific HA.

Vijay

>>> way for a collection of unicast server addresses to get assigned to 
>>> an anycast address, except for static configuration. So how would the 
>>> At least, with the DNS solution, the update of the DNS can be 
>>> automated using dynamic DNS.
>>>
>>>                        jak
>>>

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 25 Jul 2006 10:40:37 +0200

Hi Vijay, 

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Montag, 24. Juli 2006 19:27
> To: Kilian Weniger
> Cc: James Kempf; [email-masked]

Maybe not for fine-grained load balancing, but for coarse-grained load
balancing or load distribution. 
draft-ietf-grow-anycast-04.txt says:

  "Load-balancing between Anycast Nodes is typically difficult to
   achieve (load distribution between nodes is generally unbalanced in
   terms of request and traffic load).  Distribution of load between
   nodes for the purposes of reliability, and coarse-grained
   distribution of load for the purposes of making popular services
   scalable can often be achieved, however."

The draft also states load distribution and DoS resilience as objective
for anycasting:

  "1.  Coarse ("unbalanced") distribution of load across nodes, to allow
       infrastructure to scale to increased numbers of queries and to
       accommodate transient query peaks;

   2.  Mitigation of non-distributed denial of service attacks by
       localising damage to single anycast nodes;"

Anyhow, in my proposal the IKE_SA_INIT anycasting is not primarily for
load balancing, but for load distribution and reliability. The actual
load balancing can be done by forwarding the IKE_SA_INIT by the receiver
HA to a specific HA. 

> message to an anycast address routing decides which HA receives
 
Yes, you would need HA-to-HA communication.

The HA receiving the anycast IKE_SA_INIT would forward it to an HA that
is able to serve the MN and that is not overloaded. The forwarding could
be done by encapsulating the IKE_SA_INIT (in new message or
IP-in-IP/Ipsec SA).

Note that it is assumed that all HAs know or can determine the load of
other HAs on the link and that they know or can determine which HA(s)
are able to serve a specific MN (pre-configured rules or by querying a
server such as AAA). How this is done is TBD, but I guess this is needed
for the HA switch solution as well.

> same link, I wonder if anycast gets any load balancing at all.

There are multiple possible techniques to deploy anycast in such
scenario, some of them might be applicable. 
RFC1546 describes one that is based on ARP: 

  "On a shared media network, such as an Ethernet and or Token Ring, it
   must be possible to transmit an anycast datagram to a server also on
   the same network without consulting a (possibly non-existent) router.
   There are at least two ways this can be done.

   One approach is to ARP for the anycast address.  Servers which
   support the anycast address can reply to the ARP request, and the
   sending host can transmit to the first server that responds.  This
   approach is reminiscent of the ARP hack (RFC 1027) and like the ARP
   hack, requires ARP cache timeouts for the anycast addresses be kept
   small (around 1 minute), so that if an anycast server goes down,
   hosts will promptly flush the ARP entry and query for other servers
   supporting the anycast address."

draft-ietf-grow-anycast-04.txt mentiones hash-based methods for
*equal-cost paths*:

  "...applying equal-cost
   multi-path (ECMP) selection algorithms which cause a single node to
   be selected for a single multi-packet transaction.  For an example of
   the use of hash-based ECMP selection in anycast service distribution,
   see [ISC-TN-2004-1].

  "ther ECMP selection algorithms are commonly available, including
   those in which packets from the same flow are not guaranteed to be
   routed towards the same destination.  ECMP algorithms which select a
   route on a per-packet basis rather than per-flow are commonly
   referred to as performing "Per Packet Load Balancing" (PPLB)."

-Kilian

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 25 Jul 2006 10:48:26 +0200

Right, I assumed a more or less stable anycast group. BTW, I'm not
against the DNS solution per se. It may make sense to combine it with
other methods, e.g., if anycast is used, different anycast HA addresses
could be obtained from DNS for different mobility services
("_mip6._ipv6.example.com" for MIPv6, "_nemo._ipv6.example.com" for
NEMO, "_dsmip6._ipv6.example.com" for DSMIPv6 etc.).

-Kilian

> Sent: Montag, 24. Juli 2006 21:17
> To: James Kempf
> Cc: Kilian Weniger; [email-masked]

---

From: "James Kempf" <[email-masked]>
Date: Tue, 25 Jul 2006 09:36:30 -0700

jak>> How would this be any better than having the MN first contact the HA 
and receiving a rejection, then having the MN contact another HA? It seems 
to me like this would distribute the load of forwarding to the MN, so the 
first HA - which might already be close to its load limit - wouldn't have to 
do any extra work. Just fire off a simple rejection of the IKE transaction.

jak>> It also wouldn't require an additional HA-HA load balancing protocol.

  "...applying equal-cost

jak>> I don't see any routing based metric as being particularly useful in 
this case. The figure of merit in terms of which server gets traffic isn't 
primarily going to be routing. It might be load, or some other factor, like 
having particular HAs serve VoIP v.s. best effort traffic.

                 jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 25 Jul 2006 09:38:39 -0700

Combining anycast with DNS is certainly an option. We could put something 
about that into the split draft. Anybody else have an opinion on that?

But I think there is a general problem with using anycast for server load 
balancing, or in any case where the measure for which server gets the 
traffic isn't some routing-based metric. This isn't something the MIP6 WG 
can take up, though.

                jak

----- Original Message ----- 
From: "Kilian Weniger" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>; "James Kempf" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 25, 2006 1:48 AM
Subject: RE: [Mip6] New charter item: HA assignment

-Kilian

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 25 Jul 2006 19:04:18 +0200

> Sent: Dienstag, 25. Juli 2006 18:37
> To: Vijay Devarapalli; Kilian Weniger
> Cc: [email-masked]

The concern was that the initial HA should not be the same for all new
MNs starting the bootstrapping procedure in a certain period of time.
Otherwise all new MNs may be blocked or delayed when the initial HA is
overloaded or under attack ro completely unavailable during this period
of time. The idea was to anycast the IKE_SA_INIT to ensure that the
initial HA is not the same for all new MNs starting the bootstrapping
procedure. Consequently, only a subset of the new MNs would be
blocked/delayed...

Another option would be that the MNs use some randomization in selecting
the initial HA from the HA list obtained via DNS (i.e., not always
selecting the first HA with the highest weight). 

> jak>> It also wouldn't require an additional HA-HA load 

Ok, I was comparing with the HA switch mechnism, which would need
information about the load of other HAs to propose a new (low-loaded) HA
to the MN.

> having particular HAs serve VoIP v.s. best effort traffic.

As I said, the purpose of anycasting the IKE_SA_INIT was to ensure that
the initial HA for bootstrapping is not the same for all MNs. The actual
load balancing and QoS/MN-specific HA selection would be done by
forwarding the IKE_SA_INIT by the receiver HA to another HA.

-Kilian

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Jul 2006 11:51:54 -0700

James Kempf wrote:
> Combining anycast with DNS is certainly an option. We could put 
> something about that into the split draft. Anybody else have an opinion 
> on that?

the MN using DNS to obtain the anycast address for the home
agents is briefly mentioned in RFC 3775. see appendix A.5.
but we should elaborate more on this in the split scenario
solution draft.

Vijay

> But I think there is a general problem with using anycast for server 
> load balancing, or in any case where the measure for which server gets 
> the traffic isn't some routing-based metric. This isn't something the 
> MIP6 WG can take up, though.
> 
>                jak
> 
> ----- Original Message ----- From: "Kilian Weniger" 
> <[email-masked]>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 25 Jul 2006 12:31:46 -0700

Right, but that is for DHAAD. I thought the proposal here was for the MN to 
send the IKE_SA_INIT to the anycast address, for the anycast address to 
forward it to an HA, then for that HA to respond.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Jul 2006 14:24:19 -0700

James Kempf wrote:
> Right, but that is for DHAAD. I thought the proposal here was for the MN 
> to send the IKE_SA_INIT to the anycast address, for the anycast address 
> to forward it to an HA, then for that HA to respond.

ofcourse. just pointing that configuring an anycast address
in the DNS instead of the actual HA IPv6 address was written
up in RFC 3775. I guess it would be the same anycast address
whether it is used for DHAAD or IKE_SA_INIT.

Vijay

>>> something about that into the split draft. Anybody else have an 
>>> opinion on that?
>>
>>> load balancing, or in any case where the measure for which server 
>>> gets the traffic isn't some routing-based metric. This isn't 
>>> something the MIP6 WG can take up, though.
>>>
>>>                jak
>>>
>>> To: "Vijay Devarapalli" <[email-masked]>; "James 
>>> Kempf" <[email-masked]>
>>> Cc: <[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 26 Jul 2006 14:03:50 +0200

> something about that into the split draft. Anybody else have an

I do, I think the text to be put should say something about the anycast
address as the AAAA record for an fqdn of HA.  I think it should also
say something about IPsec using anycast addresses and, if impossible -
why, then IANA-reserve an apparently-anycast (not really anycast)
address that works ok with IPsec.

> something the MIP6 WG can take up, though.

I think I agree.

Alex

> <[email-masked]> To: "Vijay Devarapalli"
> <[email-masked]>; "James Kempf" 
> <[email-masked]> Cc: <[email-masked]> Sent: Tuesday, July
> 25, 2006 1:48 AM Subject: RE: [Mip6] New charter item: HA assignment
> 
> 
>  other methods, e.g., if anycast is used, different anycast HA
> addresses could be obtained from DNS for different mobility services 
>> -----Original Message----- From: Vijay Devarapalli
>> [mailto:[email-masked]] Sent: Montag, 24. Juli
>> 2006 21:17 To: James Kempf Cc: Kilian Weniger; [email-masked] 
>>> I thought the whole point of  the anycast proposal  and Kilian
>>> and Jean-Marie's argumet against DNS was load balancing and that
>>> DNS is insufficient because it does not provide fast enough
>> dynamic update. If
>> users to the right HA. you can have a pretty stable anycast group
>> and still direct the MN to a specific HA.
>> 
>> Vijay
>> 
>>> 
>>> 
>>> jak
>>> 
>>> <[email-masked]> To: "James Kempf"
>>> <[email-masked]> Cc: "Kilian Weniger"
>>> <[email-masked]>;
>> <[email-masked]>
>>> Sent: Monday, July 24, 2006 12:08 PM Subject: Re: [Mip6] New
>>> charter item: HA assignment
>>> 
>>> 
>>>> hi Jim,
>>>> 
>>>>> <[email-masked]> To: "Kilian Weniger"
>>>>> <[email-masked]> Cc: "James Kempf"
>>>>> <[email-masked]>; <[email-masked]> Sent: Monday,
>>>>> July 24, 2006 10:26 AM Subject: Re: [Mip6] New charter item:
>>>>> HA assignment
>>>>> 
>>>>> 
>>>>>> Kilian Weniger wrote:
>>>>>> 
>>>>>>> However, the problem depends on how the initial HA is
>>>>>>> selected. Anycasting can be used to prevent that new MNs
>>>>>>> select
>> the same initial
>>>>>> is there another instance of using anycast for load
>>>>>> balancing. just curious.
>>>>>> 
>>>>>>> But if this is done, you can easily get rid of the
>>>>>>> unnecessary SA
>> establishment and the
>>>>>> how do you do this? you would still need a HA-to-HA
>>>>>> protocol to forward the IKE_SA_INIT message to another HA.
>>>>>> when you send a message to an anycast address routing
>>>>>> decides which HA receives the message.
>>>>>> 
>>>>>> "nearest" means nearest by routing hops. when all the HAs
>>>>>> on the same link, I wonder if anycast gets any load
>>>>>> balancing at all.
>>>>>> 
>>>>>> Vijay
>>>>>> 
>>>>>>>> _______________________________________________ Mip6
>>>>>>>> mailing list [email-masked] 
>>>>>>> _______________________________________________ Mip6
>>>>>>> mailing list [email-masked] 
> _______________________________________________ Mip6 mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
>

---

From: "James Kempf" <[email-masked]>
Date: Wed, 26 Jul 2006 09:00:23 -0700

Alex,

> address that works ok with IPsec.

I don't think the anycast address should be included in the quad A record 
for an HA. If an HA is advertised in the DNS, then the address should be the 
address for that HA, just as for any other node. Otherwise, the semantics of 
what is an not a quad A for an HA become muddy.

However, I do think that an anycast fqdn could be included in a SRV RR. The 
fqdn would resolve to an anycast address. Perhaps there is some naming 
convention on the fqdn for anycast HA addresses  (like "www" for World Wide 
Web servers or "ftp" for FTP servers). This would make the semantics clear.

Regarding IPsec using anycast addresses, I believe the idea here is that the 
MN initiates the IKE transaction with the anycast address, which then 
forwards it (using some undetermined algorithm) to an HA. The MN then 
continues the IKE transaction with the HA at the HA's unicast address. I 
don't believe that the idea is that the MN's MIP6 signaling protected with 
IPsec goes to the anycast address after the initial forwarded IKE packet. 
The node hosting the anycast address won't keep any IKE state. It just acts 
as a forwarding agent.

In any event, we'll need to check with the IKE guys whether this is an 
appropriate approach. I'm not sure whether the IKE Initiatator can switch 
destination addresses in midstream, after it has started a transaction. I 
don't think there is a security issue, because authentication happens based 
on the server cert and client credentials after the IKE_SA_INIT but there 
might be an implementation issue with how IKE implementations typically 
work.

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 26 Jul 2006 19:37:20 +0200

James Kempf wrote:
> Alex,
> 
>> I do, I think the text to be put should say something about the 
>> anycast address as the AAAA record for an fqdn of HA.  I think it 
>> should also say something about IPsec using anycast addresses and,
>>  if impossible - why, then IANA-reserve an apparently-anycast (not
>>  really anycast) address that works ok with IPsec.
>> 
> 
> I don't think the anycast address should be included in the quad A 
> record for an HA. If an HA is advertised in the DNS, then the address
>  should be the address for that HA, just as for any other node. 
> Otherwise, the semantics of what is an not a quad A for an HA become
>  muddy.

I'm not sure about the semantics of quad A being confused(?) Is the
definition of quad A saying it MUST be a unicast address? or just that
it has to be 128bit long?  I thought one can put a multicast 128bit
address as a quad A (and a 32bit multicast as A).

> However, I do think that an anycast fqdn could be included in a SRV 
> RR. The fqdn would resolve to an anycast address.

Now I'm confused.  If the fqdn resolves into an anycast address then the
only way to achieve that is to have the anycast addres as quad A, no?

> Perhaps there is some naming convention on the fqdn for anycast HA 
> addresses  (like "www" for World Wide Web servers or "ftp" for FTP 
> servers). This would make the semantics clear.

Last time I checked the SRV RFC there wasn't one.

> Regarding IPsec using anycast addresses, I believe the idea here is 
> that the MN initiates the IKE transaction with the anycast address, 
> which then forwards it (using some undetermined algorithm) to an HA.
> The MN then continues the IKE transaction with the HA at the HA's 
> unicast address. I don't believe that the idea is that the MN's MIP6
>  signaling protected with IPsec goes to the anycast address after the
>  initial forwarded IKE packet. The node hosting the anycast address 
> won't keep any IKE state. It just acts as a forwarding agent.

The node hosting the anycast address may become a single point of 
failure, that's why the anycast address should be "hosted" by each HA, no?

In a way, it is even possible to define a new multicast address, to 
which all HAs subscribe, valid on the home link, and the MN does 
IPsec'ed DHAAD Request to that multicast address; provided that IPsec 
implementation accepts a multicast address as part of the SA.

> In any event, we'll need to check with the IKE guys whether this is 
> an appropriate approach. I'm not sure whether the IKE Initiatator can
>  switch destination addresses in midstream, after it has started a 
> transaction. I don't think there is a security issue, because 
> authentication happens based on the server cert and client 
> credentials after the IKE_SA_INIT but there might be an 
> implementation issue with how IKE implementations typically work.

Yes.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Wed, 26 Jul 2006 10:47:33 -0700

Alex

> address as a quad A (and a 32bit multicast as A).

My point was if the fqdn is intended to identify an HA, then it should 
include an HA address in the quad A. If an fqdn for an anycast address 
acting as a front end for a group of HAs is desired, then it should be 
identified as such. When an application goes to resolve the fqdn, I think it 
should know what it is getting.

>> However, I do think that an anycast fqdn could be included in a SRV RR. 
>> The fqdn would resolve to an anycast address.
>

See above.

> Last time I checked the SRV RFC there wasn't one.

Not for the SRV RR. For the anycast fqdn. For example:

mipanycast-625.msp.com -Anycast address for 625 subnet in msp's nettwork
ha1-625.msp.com - HA1 in 625 subnet

> The node hosting the anycast address may become a single point of failure, 
> that's why the anycast address should be "hosted" by each HA, no?
>

My understanding is that the way most anycast is deployed, the address is 
hosted by a router.

> In a way, it is even possible to define a new multicast address, to which 
> all HAs subscribe, valid on the home link, and the MN does IPsec'ed DHAAD 
> Request to that multicast address; provided that IPsec implementation 
> accepts a multicast address as part of the SA.
>

I don't know how DHAAD will help. The issue is establishing the IPsec SA 
with the home agent, not finding a home agent. The whole point of using the 
anycast is to have the home agent assigned, not selected by the MN.

           jak

---

From: Greg Woodhouse <[email-masked]>
Date: Wed, 26 Jul 2006 11:02:21 -0700 (PDT)

> address as a quad A (and a 32bit multicast as A).

Way back in RFC 1034, A records are defined as identifying host
addresses. Can an anycast address be called a host address? I don't
know if DNSv6 addresses this issue (I'll have to look), but there is
certainly a problem here: The semantics of anycast addresses are not
the same as the semantics of unicast addresses, and if both are
identified by AAAA records, there is at least an implication that they
are the same sort of "thing" when they are not. On the other hand, you
may wish the FQDN in a URI to be anycast for load balancing purposes. 

Of course, this isn't really a mobility issue.

===
Gregory Woodhouse  <[email-masked]>

"Judge a man by his questions not his answers."
--Voltaire

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 26 Jul 2006 20:57:12 +0200

James Kempf wrote:
>>  definition of quad A saying it MUST be a unicast address? or just 
>> that it has to be 128bit long?  I thought one can put a multicast 
>> 128bit address as a quad A (and a 32bit multicast as A).
>> 
> 
> My point was if the fqdn is intended to identify an HA, then it 
> should include an HA address in the quad A. If an fqdn for an anycast
>  address acting as a front end for a group of HAs is desired, then it
>  should be identified as such. When an application goes to resolve 
> the fqdn, I think it should know what it is getting.
> 
>>> However, I do think that an anycast fqdn could be included in a 
>>> SRV RR. The fqdn would resolve to an anycast address.
>> 
>> Now I'm confused.  If the fqdn resolves into an anycast address 
>> then the only way to achieve that is to have the anycast addres as 
>> quad A, no?
>> 
> 
> See above.
> 
>>> Perhaps there is some naming convention on the fqdn for anycast 
>>> HA addresses  (like "www" for World Wide Web servers or "ftp" for
>>>  FTP servers). This would make the semantics clear.
>> 
> mipanycast-625.msp.com -Anycast address for 625 subnet in msp's 
> nettwork ha1-625.msp.com - HA1 in 625 subnet
> 
> My understanding is that the way most anycast is deployed, the 
> address is hosted by a router.

If deploying anycast needs a single point of failure then I'd suggest
not using anycast addresses for DHAAD.  I.e. modify DHAAD such that it
does not use anycast addressing at all.

The implementation is really straightforward.  Decide on a unique
address to be assigned on every HA, with the prefix of the home link.
Assign this address on every HA (in addition to the unique
EUID-64+prefix address).  Have IPsec SA on MN between its HoA and this
address.  The rest will work.  The HAs synchronize themselves about who
should reply and who should not, the MN chooses the MN at top of list.

>> IPsec'ed DHAAD Request to that multicast address; provided that 
>> IPsec implementation accepts a multicast address as part of the SA.
>> 
>> 
>> 
>> 
>> 
> 
> I don't know how DHAAD will help. The issue is establishing the IPsec
>  SA with the home agent, not finding a home agent. The whole point of
>  using the anycast is to have the home agent assigned, not selected 
> by the MN.

James, let me detour here.

I don't see the link between the necessity of anycast addresses and the
necessity of assigning the HA.  DHAAD already does anycast and DHAAD can
help achieve the result of assigning the HA.

HA stops responding BAck, change preferences in RAs so a different HA
gets on top of the list.  Then MN does DHAAD and obtains the address of
a different HA (the address that operator decide to be on top of the
list).  Alternatively, HA instead of stopping BAck to provoke MN to do
DHAAD, it  can send a ha-switch-like message to MN to instruct it to do
DHAAD.  There can even be a "Unsolicited DHAAD Reply" periodic message,
just like unsolicited NA.

Analogically, DHCP works this way:  Server sends Reconfigure to Client
and Client initiates a new transaction to obtain whatever new parameters
the admin decides to re-number.  DHCPv6 does not seem to have a
mechanism for a Server to assign another Server to a Client.

Re the operator needs to _enforce_ an HA to a MN, not
giving it any option.  A protocol with similar semantics is Router
Renumbering.  An admin propagates a Router Renumbering message to a
bunch of routers.  But even then the router to be renumbered has the
freedom to execute it or not.  (1) there is a Result Message sent by the
router back to admin.  (2) prior to executing the command, the router
must successfully match-prefix with a prefix in its routing table (if
that prefix is not in its table because ospf might have removed it, the
renumbering fails).

Assigning the HA should happen this way too (like in DHCP: HA sends a
trigger and MN initiates the reconfiguration, like in RouterRenum: MN
has freedom to execute a received command or not).

My two cents worth,

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 26 Jul 2006 12:20:24 -0700

James Kempf wrote:
> appropriate approach. 

Francis did check with the IPsec folks before
draft-dupont-ikev2-haassign was written up. there was some
discussion on the IPsec mailing list on this.

I'm not sure whether the IKE Initiatator can
> authentication happens based on the server cert and client credentials 
> after the IKE_SA_INIT but there might be an implementation issue with 
> how IKE implementations typically work.

the draft uses a cookie based mechanism described in section
2.6 of RFC 4306. if an IKE implementation supports section
2.6 then there is no concern. IMO, the following is the only
difference. RFC 4306 says

    To accomplish this,
    a responder SHOULD -- when it detects a large number of half-open
    IKE_SAs -- reject initial IKE messages unless they contain a Notify
    payload of type COOKIE. It SHOULD instead send an unprotected IKE
    message as a response and include COOKIE Notify payload with the
    cookie data to be returned.

draft-dupont-ikev2-haassign says
    1.  the MN sends an IKE_SA_INIT request to the HA anycast address
    2.  the anycast receiver forwards the request to the "best" HA
    3.  the HA answers using its own address as the source address and
        includes an "under attack" cookie in its replies

the trigger at the responder for including the COOKIE Notify
payload is different.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 26 Jul 2006 12:27:35 -0700

I don't think there is any restriction on placing an anycast
address in a AAAA record. I am not certain, though.

Vijay

Greg Woodhouse wrote:
>> that

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Jul 2006 23:49:28 +0200

In your previous mail you wrote:

=> as Vijay mentioned this was done.

   I'm not sure whether the IKE Initiatator can switch 
   destination addresses in midstream, after it has started a transaction.

=> in fact it can only when no state has been built (this gave the idea
behind the IKE HA assignment I-D).

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Jul 2006 23:51:18 +0200

provided that IPsec 
   
=> it should not in this context...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Jul 2006 23:53:14 +0200

To accomplish this,

   
Thanks Vijay! BTW this mechanism provides assignment and HA switch
re-assignment, so they should cover all scenarios, shouldn't they?

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Jul 2006 23:54:31 +0200

=> I agree. IMHO the only constraint is that the client should be
ready to get an anycast address.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 27 Jul 2006 00:00:06 +0200

=> this is not true: it works but as it needs the key online usually
it is considered as not very desirable.

=> I fact the reason to not use dynamic upate of SRV RRs for load balancing
is already explained in RFC 2782, so why not follow the explicit
not recommendation about this?

=> not MIPv6 guys are already tired by random proposals to addition to
their protocols by MIPv6 guys (:-)...

Regards

---

From: "James Kempf" <[email-masked]>
Date: Wed, 26 Jul 2006 13:28:40 -0700

> should reply and who should not, the MN chooses the MN at top of list.

I think Francis' way of doing it is simpler. The operater can deploy the 
anycast address wherever they want, and use it as a front end to a 
collection of HAs.

> has freedom to execute a received command or not).

Well, we clearly disagree on this, Alex.

            jak

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 27 Jul 2006 21:07:03 +0900

Hi Alex

Brian seems not to respond you any more, but let me try again:-)

 From MN side, there is big difference between CN and HA,
which is home registration flag in BUL.
If MN sends BU to a HA without home flag, the HA can be treated as a CN.
Note that the HA shouldn't be one with which MN associates.

Otherwise, HA is HA, and NOT CN.

Some MN may discard BRR from its HAwhich bul entry has the home flag.

regards,
ryuji

Alexandru Petrescu wrote:
>>>>>>> Another way is for the new HA to send Binding Refresh Request to 
>>>>>>> MN (even if it has no BC entry for it).
>>>>>>
>>>> I don't know how you can interpret 3775 (or implement it) such that 
>>>> a HA can be a CN of the same MN at the same time.
>>>
>>> In this way MN does not need to implement additional timer of 
>>> receiving BAck, only a timer for re-transmitting BU and to respond to 
>>> BRR.
>>>
>>> exercise indeed, but I'm tempted to do it because I also had to do it 
>>> when thinking CN can be a MN.  And, if one thinks NEMOv6 then, and MN 
>>> is a MR and MR can be a HA for mobiles in its moving network... CN 
>>> can be a HA.
>>>
>>> In the end, the BRR message should be implemented as send and receive 
>>> in any entity running Mobile IPv6: CN, HA, MH, MR.
>>
>> I'll agree to disagree.
>>
>>> Take this 3775 text:
>>>> use, it MAY send a Binding Refresh Request message to the mobile 
>>>> node in an attempt to avoid this overhead and latency due to 
>>>> deleting and recreating the Binding Cache entry.
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Jul 2006 14:38:38 +0200

> Brian seems not to respond you any more, but let me try again:-)

That's fine :-)

> From MN side, there is big difference between CN and HA, which is
> home registration flag in BUL. If MN sends BU to a HA without home
> flag, the HA can be treated as a CN. Note that the HA shouldn't be
> one with which MN associates.

That is right.  MN puts a specific flag in BU to HA, and not to CN.  But 
BRR is sent by CN (not by MN).  Anyways.

> Otherwise, HA is HA, and NOT CN.

Ok.

> Some MN may discard BRR from its HAwhich bul entry has the home flag.

Is this requested to happen so?  Is this behaviour a MUST, a SHOULD, a MAY?

Alex

---

From: "James Kempf" <[email-masked]>
Date: Thu, 27 Jul 2006 08:51:31 -0700

> re-assignment, so they should cover all scenarios, shouldn't they?

Not sure what you mean by switch reassignment, but I think there is still a 
need for a message from the HA to the MN to tell it when to switch if the HA 
is, for example, going down. The switch message may include an anycast 
address, or it may include a unicast address for specific HAs.

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Jul 2006 17:58:11 +0200

James Kempf wrote:
> Not sure what you mean by switch reassignment, but I think there is 
> still a need for a message from the HA to the MN to tell it when to 
> switch if the HA is, for example, going down. The switch message may 
> include an anycast address, or it may include a unicast address for 
> specific HAs.

Would an Unsolicited DHAAD Reply fit the bill?

I agree there is a need for a message with the semantics you propose, 
and I do know that ha-switch is a potential good candidate.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Thu, 27 Jul 2006 09:08:28 -0700

Actually, no. I was thinking of draft-ietf-mip6-ha-switch-00.txt.

        jak

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Francis Dupont" <[email-masked]>; "Vijay Devarapalli" 
<[email-masked]>; <[email-masked]>; "Kilian Weniger" 
<[email-masked]>
Sent: Thursday, July 27, 2006 8:58 AM
Subject: Re: [Mip6] New charter item: HA assignment

>> Not sure what you mean by switch reassignment, but I think there is still 
>> a need for a message from the HA to the MN to tell it when to switch if 
>> the HA is, for example, going down. The switch message may include an 
>> anycast address, or it may include a unicast address for specific HAs.
>
> I agree there is a need for a message with the semantics you propose, and 
> I do know that ha-switch is a potential good candidate.
>
> Alex
>
>

---

From: Francis Dupont <[email-masked]>
Date: Thu, 27 Jul 2006 23:52:29 +0200

> re-assignment, so they should cover all scenarios, shouldn't they?
   
   Not sure what you mean by switch reassignment,

=> HA switch provides re-assignment (i.e., not initial assignment).

   but I think there is still a need for a message from the HA to the
   MN to tell it when to switch if the HA is, for example, going down.

=> I agree: there is a clear operational need for this.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 27 Jul 2006 23:54:02 +0200

=> no, the message must be protected.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Jul 2006 20:13:53 +0200

Francis Dupont wrote:
>>>> Thanks Vijay! BTW this mechanism provides assignment and HA 
>>>> switch re-assignment, so they should cover all scenarios, 
>>>> shouldn't they?
>>> 
>>> Not sure what you mean by switch reassignment, but I think there
>>> is still a need for a message from the HA to the MN to tell it
>>> when to switch if the HA is, for example, going down. The switch
>>> message may include an anycast address, or it may include a
>>> unicast address for specific HAs.
>> 

> => no, the message must be protected.

I guess Reply being an unicast ICMP, could be protected.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 29 Jul 2006 02:15:50 +0200

> Actually, no. I was thinking of draft-ietf-mip6-ha-switch-00.txt.

The draft looks good.

It describes a message exchange between HA and MN.  A HA
Switch message (a Mobility Header) is sent by HA to MN, optionally
providing a list of alternate Home Agents.  The MN replies back with a
BU requesting deletion of the current BCE.  Subsequently the MN performs
IKE with a randomly chosen HA in the provided list or HA discovery
otherwise.  The HA Switch message uses IPsec.

Could you please clarify whether HA Switch considers only HAs on a same
home link, or can accomodate on different links too.  Because if the
latter then it's clear that a Home Address should be acquired too, in
which case ongoing sessions will be interrupted, a thing which should
absolutely be mentioned.

> A Mobile IPv6 home agent provides mobile nodes with two basic 
> services - a rendezvous server where correspondent nodes can find the
>  current care-of address for the mobile node, and as an overlay 
> router to tunnel traffic to/from the mobile node at its current 
> care-of address.

I think this is the first time I see this description of Mobile IPv6 HA.
  I like it (HA=rdv point+overlay router).

> Periodically, a mobility service provider may want to shut-down home
>  agent services at a set of IPv6 addresses and bring service back up
>  at a new set of addresses.

Makes sense.

> There are various reasons why a mobility service provider might want
>  to do this; an example is if the service provider revokes the
> account of a user it has reason to believe might use the old home
> agent address to disrupt service for other users.  With a signaling 
> message, the service provider could inform mobile nodes to look for a
>  new home agent.

Makes no sense.

It's sufficient for HA to revoke the key of a disruptive MN and it's
recommended to do that instead of renumbering its HAs and inform all
other MNs to switch, too much work.

It might have made sense if a majority of MNs were disruptive.

> The home agent addresses field should be constructed as described in 
> Section 10.5.1 of [3775].

That cited section is 2-pages long and starts with a description on how
to build a home agent list and ends with what should be put in the Home
Agent Addresses field.

What that means is basically (1) how to collect information from HA RAs
and (2) how to sort the HA addresses in the Home Agent Addresses field.

But this spec mentions scenarios "overloaded", "load balancing",
"maintenance", "functional load balancing", "HA renumbering" without
providing means to convert these words into actual Preference and
Lifetime values in the RA.  I'd have preferred that.

Also, this spec says that MN chooses randomly the HA in the HA list, so
no reason to order the list before sending it.

> 4.2 Retransmissions

It's good to have re-transmissions.

However, since their very goal is to provide reliability against packet
loss or re-ordering it would be interesting to have an id in the
message, and echoed back.

Doing so would avoid a situation where the HA sends a switch to MN
suggesting another HA1, then HA1 goes down, and HA sends another switch
with HA2 inside.  If the first switch message is lost and HA receives
BU/0 then MN has no more connectivity (because HA1 is down and HA
believes MN responded to the right switch message).

> Upon receipt of a Home Agent Switch message, the mobile node MUST 
> stop using its current home agent for services and MUST delete its 
> home binding by sending a Binding Update message as described in [2].
> 
> 
> 
I'm not sure about the MUST above, I'd rather make it a SHOULD.  Because
otherwise someone may come up with the idea that even if the HA is
loaded and needs to switch MN to another HA then MN is probably in a
situation where it absolutely wants to continue using this HA, so send
it back a new message "I don't want to switch".  When can this happen?
If MN is in the middle of a HoTI/HoT it surely doesn't want to switch HAs.

> If the Home Agent Switch message contains a list of alternate home 
> agent addresses, the mobile node SHOULD select a home agent at random
> 
> 
> 
... so no need to order the HA list (?).

My two cents worth.

Alex

---

From: liujixing <[email-masked]>
Date: Sat, 29 Jul 2006 09:59:04 +0800

A HA Switch message  is sent by HA to MN, optionally
providing a list of alternate Home Agents. The HA Switch message may also providing a lifetime for maintaining mobility service continually. The MN can perform
IKE with a chosen HA in the provided list or HA discovery otherwise before the lifetime expires.  The HA will stop providing service to the MN when the lifetime expires.

In addition to the Mobility Header, could the ICMP message be used to send HA Switch? The ICMP message(a new type needed)  can be protected using IPSec. 

thanks.