Subject: RE: [mobile-ip] Mipv6 issue #157: Address collision action (was: AD review comments)

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Sat, 16 Nov 2002 00:36:55 +0100

Jari,

  > However, after some discussion I now realize that this is perhaps a
  > more general problem in IPv6 specifications. Mobile nodes 
  > are particularly
  > vulnerable to this problem, e.g., through malicious 
  > attackers doing it
  > on purpose. But the same situation can also happen even for 
  > stationary
  > nodes. For instance, an attacker could see over unprotected 
  > WLAN when
  > a node comes up and tries to do DAD, and then by responding the node
  > can be disabled.
  > 
  > It is also true that we have a working group, SEND, to deal 
  > with this
  > and other issues related to IPv6 control functionality. It's better
  > to deal with this problem there in a general way.
  > 
  > Proposed text is removing all of Section 7.7.

=> Isn't this a bit drastic? What if there is a genuine
collision? shouldn't we try to generate a new care-of address?
Removing the whole section would mean that the MN has 
to stop communicating...
Now, I realise collision is very rare if a propoer iid
(random) was generated, but we don't know that every
node will have a proper RNG for the iids. So as a 
safe precaution (just like DAD is a safety precaution
for a rare case) I would suggest that the MN tries 
one more time. I think the action in 2462 is too 
drastic for the MN. 

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 15 Nov 2002 17:16:20 -0800

> one more time. I think the action in 2462 is too

I agree with Hesham. we had a long discussion regarding this
and finally concluded that disabling the interface is a drastic
step. can somebody give me a good reason as to why the interface 
should be disabled, if DAD fails?

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Fri, 15 Nov 2002 18:00:30 -0800

I agree with Jari and Thomas. I think the MIPv6 spec should be based on 2461 &
2462 and extensions should be discussed in a separate document.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Sat, 16 Nov 2002 05:35:01 +0200

Vijay, Hesham,

The action *is* too drastic. I don't think anyone is arguing about
that. So there is a problem. But I think the question Thomas was
raising was whether the problem should be fixed here and only for
mobile IP, or in a more general way in SEND or as an update of the
ND specifications.

There are a few things which speak in favor of a separate specification:

- The problem can appear also in non-MIPv6 communications.
- A better fix can be specified in SEND
- Specification length is reduced

Jari

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 15 Nov 2002 22:00:20 -0800

Hello Jari,

I think we have to have it so that the base specification doesn't
depend on currently nonexistent specifications in order to get
reasonable performance.  For mobile nodes, the proposed
restriction is not reasonable, and if SEND makes a better way
then it will be simple for SEND to point out what is to be obsoleted
(if aything) in the base Mobile IPv6 specification.

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Sat, 16 Nov 2002 05:28:50 -0800

Hi Charlie,

I would rather see the base specification concentrate on the end to end aspects
of MIP and not the local link aspects. One of the nice characteristics of the
MIPv6 design is that, with the elimination of the Foreign Agent, this becomes
very doable. With the conclusion of the RO security work, the end to end aspects
of MIP are now quite clear and ready for standardization, the local link aspects
are still quite murky.

With regard to your point about performance, even if a few exceptions to 2462
were put in, there would be far more work needed to make MIP handover
performance be optimal. Rather that try to do it piecemeal, I'd like to see a
consistent architectural approach taken to designing the local link aspects.
This is a good topic for the WG charter discussion.

            jak

----- Original Message -----
From: "Charlie Perkins" <[email-masked]>
To: "Jari Arkko" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, November 15, 2002 10:00 PM
Subject: Re: [mobile-ip] Mipv6 issue #157: Address collision action (was:AD
review comments)

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 16 Nov 2002 07:17:32 -0800

Hello Jim,

I don't think that every point about RFC 2462 is murky in the draft, and
the point anyway is to make something that works irrespective of the
local link aspects.  I do not agree to put in anything that ties Mobile IPv6
to a particular local link.  I also do not agree with your blanket characterization
that no exceptions to RFC 2462 are possible.  I think we have to consider
each point separately.  In other words, what you characterize as "piecemeal"
is what I would characterize as good incremental engineering.

I'd also point out that these items are not news within the IPv6 working
group.  For a while there, Dave Johnson was making presentations at
practically every IPng working group meeting and most of the design aspects
were very clear.  They have been for a long time.  Saying "it's all murky"
just contradicts reality.

Regards,
Charlie P.

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 18 Nov 2002 11:23:08 -0800

Jari,

I thought we were splitting Thomas's comments on ND changes into 
multiple issues. and treating them as separate issues. we could 
resolve each one separately. for example, take optimistic DAD. 
it would be okay to take up this optimization separately. we can
remove it from the MIPv6 spec. but changing the router 
advertisment interval to new default values should be in the 
MIPv6 spec. we need that for faster movement detection. this is 
not a major change to RFC 2461. infact we could say that the new 
default values are only for those access routers which serve 
mobile nodes (doesnt it already?). 

turning off an interface when you have a DAD collision is
something that needs to be fixed ASAP. IMO, trying once more with 
another interface id, when you have a DAD collision is a safe 
thing to do. I dont see how it would break anything in RFC 2461.

Vijay

---

From: Greg Daley <[email-masked]>
Date: Tue, 19 Nov 2002 05:44:36 +0000

Hi Vijay,

In the presence of L2 triggers on the AP or MN, there's no need for
increased RA rate, if either JinHyeock's RA caching or FastRA 
are in use.

Since the RA interval is essentially a Router issue, and an optimization
one at that, I'm not sure it's necessary to have it in MIPv6 base.

It may just be considered one of the alternative optimizations.
The fact that it's already implemented and tested just gives
more weight to its being adopted amongst other optimizations.

Just my opinion.

Greg

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 18 Nov 2002 11:58:49 -0800

Greg,

> increased RA rate, if either JinHyeock's RA caching or FastRA

lets stick to what we have today. MIPv6 needs to ready soon.
people are planning products on it. we dont have standard 
L2 triggers yet. and we need something that will work on all
link layers.

> one at that, I'm not sure it's necessary to have it in MIPv6 base.

it is an *essential* optimization. it is absolutely needed for
movement detection. 

> more weight to its being adopted amongst other optimizations.

remember that MIPv6 does not say all routers MUST set their
router advertisement interval to these default values. it says
if needed, one SHOULD be able to configure the access routers
to the new default values.

regards
Vijay

---

From: "James Kempf" <[email-masked]>
Date: Mon, 18 Nov 2002 12:38:34 -0800

Hi Vijay,

> L2 triggers yet. and we need something that will work on all

We have a Linux 802.11 driver that implements a Link Up trigger when the MN does
a Reassociation.request(). This is not hard to do and it substantially increases
handover performance, since the MN is no longer tied to the RA frequency.

> it is an *essential* optimization. it is absolutely needed for

I agree that there should be a minimum RA interval specified in the text. The
current minimum (50 ms) seems unlikely to be used unless only legacy hosts are
to be accommodated, however, as other simple measures (such as the
abovementioned) work better without the deployment burden . If a client is being
modified for Mobile IP anyway, it is simple to add Link Up trigger support.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 18 Nov 2002 12:51:34 -0800

> handover performance, since the MN is no longer tied to the RA frequency.

oh.. we do that too.....

but this link trigger (I was told) is not available for every 802.11
card. not mentioning other link layers.

> If a client is being

:-)

Vijay

---

From: Greg Daley <[email-masked]>
Date: Tue, 19 Nov 2002 07:16:10 +0000

Hi Vijay,

Support for  quick RA on 'legacy' MN's could also be supplied
by the RA caching AP (If the service provider wanted to make sure
that the MN's get RA quickly without L2 Triggers).

Why does the RA interval modification take precedence over these
other ideas? 

Sending lots of multicast RA just makes worst case performance
a bit better at the expense of bandwidth. It's not that effective
in speeding up handovers on nodes which support link-up triggers
really.

Should we be putting this in the base spec when it's likely that 
MN wireless drivers will move toward decent L2 indications?

Greg 

Greg

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 18 Nov 2002 13:40:52 -0800

Greg,

I like these optimizations. I like AP caching an RA. I like 
L2 triggers. I like fastRA. but *nothing* is standardised
yet!! as I said, people are planning on products using MIPv6.
and we *need* some standard IP mechanism to speed up movement
detection *now*. and this should work across all link layers.

> in speeding up handovers on nodes which support link-up triggers

access routers SHOULD be configurable to send router adverts
frequently. thats all MIPv6 says.

> MN wireless drivers will move toward decent L2 indications?

till then, lets have this.

Vijay

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 18 Nov 2002 13:36:05 -0800

Hello Greg,

The point of enabling faster advertisements is that it is a possible
way to get better performance in the absence of layer-2 support.
This is not different than the situatoin for Mobile IPv4, where sending
Agent Advertisements at the faster rate is enabled in the base
specification.  Otherwise, Mobile IPv6 will suffer on all but the
specialized link layers that have additional layer 2 support.

Mobile IPv6 cannot necessitate modifications to layer 2, although
we all agree it can benefit from them.

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 18 Nov 2002 13:53:42 -0800

> card. not mentioning other link layers.

Re. all cards, there is no requirement in the 802.11 spec to surface this to the
OS, so it depends on the firmware. Each driver would have to supply this or not
as the device supported it or not. Your milage would thus vary.

Re. other link layers, together with Motorola, we did an experimental version of
a cdma2K/FMIPv4 integration that had triggers, and I think we do this with
Bluetooth too on both FMIPv4/v6, but I need to check (though it isn't much use
for fast handover with Bluetooth due to the lengthy L2 negotation time for
handover).

            jak

---

From: Greg Daley <[email-masked]>
Date: Tue, 19 Nov 2002 07:59:03 +0000

Hi Vijay & Charlie

I'm not against the RA interval being shorter, just concerned 
on 2 fronts: 

The ADs seemed to dump it in their review (along with
other optimizations).

It's not necessarily a good long-term solution.
(though it is the only current solution which doesn't use
L2 information to date).

If the WG and the ADs agree that it can go into the MIPv6 PS,
then that's fine with me. Otherwise, we can specify it 
quickly in a separate document, or in a document which 
discusses optimizations generally.

I can't see it not getting through in some form, just maybe
not in MIPv6.

Greg

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 18 Nov 2002 13:59:00 -0800

James Kempf wrote:
> as the device supported it or not. 
> 

firmware is not necessarily in my control always.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 18 Nov 2002 14:04:25 -0800

> If the WG and the ADs agree that it can go into the MIPv6 PS,

thats what this dicussion is about. Jari has listed this as
one of the issues
http://www.piuha.net/~jarkko/publications/mipv6/issues/issue154.txt.
we need to resolve this soon.

vijay

---

From: "James Kempf" <[email-masked]>
Date: Mon, 18 Nov 2002 16:43:03 -0800

> firmware is not necessarily in my control always.

If you want the card to run in infrastructure mode, how can it not be?

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 18 Nov 2002 17:15:01 -0800

> If you want the card to run in infrastructure mode, how can it not be?

I am confused. are we talking about the same thing? when I 
buy a Cisco Aironet card, the firmware is not in my control.
neither is the driver code. I cant add a link-up trigger
if the card does not provide one. 

I just buy a card, set it in infrastructre mode, set the 
bssid and start using it.

am I missing something?

Vijay

---

From: Greg Daley <[email-masked]>
Date: Wed, 20 Nov 2002 05:04:57 +0000

Hi Vijay, 

We've implemented L2 (Up/down) triggers for exactly the cards you
mentioned (Linux).  We didn't need firmware changes (wasn't too hard).

Please email me if you need to talk off line about it.

Greg

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 19 Nov 2002 11:26:44 -0800

hi Greg,

you missed the point. that was just an example (I used that 
because, I knew for sure I wont be able to get the firmware
code or the driver code for that card).

anyway we can continue offline.

Vijay