Subject: [mobile-ip] Connectathon 2003 issues for MIPv6 draft-20

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 12 Mar 2003 16:23:51 -0800 (PST)

They also apply to draft-21.

Please note that the issues were all minor- mostly
clarification issues in the draft, which contributed
to interop problems.

The implementors got together to discuss the issues 
found at the Connectathon MIPv6 draft-20 testing.

Here is a compiled list of issues brought up by the
MIPv6 implementors and the test groups at the Connectathon.

-Samita
----------------------------------------------------------
Connectathon 2003 Issue List
===============================

1. HA De-registration

   During de-registration process, MN sends BU with lifetime=0
   to HA. After successful processing HA wants to send BA
   back to MN, HA does Neighbor Soliciation to MN to update
   its neighbor cache entry. 
  
   Problem : section 11.5.4 states:
   " After the Mobile Node sends the Binding Update, it MUST be prepared
   to reply to Neighbor Solicitations from its home agent." 

   Some MN implementations don't respond if the source address of
   the NS is link-local; it only replies when source address of NS 
   from HA is global. 

   Proposal : Should the draft clarify that MN should respond to
              all scopes of NS source address ?

2. Movement Detection by the MN

   Section 11.5.1 discusses mechanisms such as:
    
      - Check default router address (link-local) and or do
        periodic NUD for the default router.
      - Check the prefix of the router advertisement

   An implementation (router) may have same link-local addresses
   on its different interfaces. Thus mobile nodes which detect
   movement by doing periodic NUD to the default router and checking
   default router's link-local address cannot detect movement
   while moving from one subnet to another subnet served by the
   same router. At Connectathon at least one implementation failed
   to detect movement for the above reason.

Proposal(s):

   * Draft should clarify that a router that  provides service to
     the mobile nodes, MUST be configured with unique link-local
     addresses on its each link.

   * Having some unique id to distinguish different ESD part of
     the link-local addresses of each interface of the router.

   * The mobile node SHOULD compare both link-local
     address of the default router(its reachability) and the prefix
     in the prefix option of router advertisement (with the prefix
     of the mobile's interface) to determine movement at the L3 level.
    
 3. Simultaneous movement of two MNs while performing RO with each-other      

    Issue  #269.

    Problem : MN/CN implementations were using the correponding MN's
              COA as dst of HOTI message while both MNs moved at the
              sametime, resulting into loss of HOTI messages
              The implementatios were using RH type2 containing 
              destination MN's home address.

    Solution : 1. Never send RH with HOTI messages. 
                  Use home-address of the corresponding MN
                  as the dst field of the HOTI message when
                  a mobile node uses RO with another mobile node

                2. Use home-address of the Mobile node in the
                destination field of the COTI message when 
                a mobile node corresponds with another mobile
                node using RO

                3. When using RO, a BU to a CN (which happens to be
                   MN) should be sent to the home address of that
                   mobile node.

4. Should CN send a BA to MN when it receives BU with 'H' bit on ?

   Problem: The spec is unclear when CN should drop the packets
            and which cases it should return BA or BE

   NOTE: At Connectathon, many implementors believed that CN should
         respond back with rate-limitation. Some of them did say that
         CN should drop the BU.
         Supporters thought it'd be helpful for MN to know earlier so
         that it can correct the problem sooner.

5. Section 9.5.1

   For example, if the last
      received sequence number was 15, then messages with sequence
      numbers 0 through 15, as well as 32784 through 65535, would be
      considered less than or equal.    ^^^^^

      There is a typo--s/32784/32783
   
6. The spec does not say that HA MUST not respond to NS when src=HOA
   before MN deregisters.

   Spec states a few steps regarding what HA should do during 
   deregistration, however the above not clear. Thus some HA
   make the mistakes easily.

7. CN and HA should always send ICMPv6 PARAM or BE messages to the
   source address of the packet without looking up the BCE routing.

   Problem scenario discussed:

   1. MN moves to a foreign link
   2. MN send BU1 to HA and creates BCE at HA
   3. MN sends BU2 (refresh) with some wrong parameters.
   4. HA looks up the BCE to respond with error

8. Can a HA be a CN to the same mobile node ?

   Problem scenario:

   1. A node acts as both HA and CN
   2. A MN sends RR messages and does BU with H=0 to this node.
       (pressumably it had been using a different HA)
   3. The same MN sends BU H=1 to the same HA/CN node

   Should this HA/CN node accept or ignore the second BU ?
   Or
   Should this HA/CN delete the old BCE and create a new BCE
   and also starts acting as HA.

  Proposal : For simplicity, it's better for HA to ignore the
             second BU.

           [ Otherwise, the combination of HA/CN and order of 
             H bit (0/1) in successive BUs make implementation
             unnecessary complex ]

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Mar 2003 15:51:41 +0200

Registered as issue #273, plus point 3 went to #269.

>               all scopes of NS source address ?

Interesting. Yes, I suppose this is necessary. I looked at
RFC 2461 but it gives some freedom for choosing the source
address, so we can't stick to one. Suggested text: "... from
either the link-local address of the home agent or from any
of its global addresses."

Question: do we need to clarify where these addresses come
from? I suppose the link-local address comes from the RA,
and the global addresses come from the PI options?

>      addresses on its each link.

Sounds pretty tough for *all* IPv6 routers.

>      the link-local addresses of each interface of the router.

But we don't have any, do we?

>      of the mobile's interface) to determine movement at the L3 level.

This seems like the only possibility, unless someone invents
something new. I'm willing to go for this, though it means that
when a router has the same link-local address, movement detection
is delayed until you see also an advertisement. Maybe its the
best we can do?

>                    MN) should be sent to the home address of that

I think we picked solution #1 in issue 269. Is this good enough
or should we discuss the other alternatives?

>          that it can correct the problem sooner.

Section 9.5.1 of draft 21:

    o  The Home Registration (H) bit MUST NOT be set.

    ...

    For packets carrying Binding Updates that fail to satisfy all of
    these tests for any reason other than insufficiency of the Sequence
    Number or expired nonce index values MUST be silently discarded.

So, you should drop the BU. My suggestion is that no
changes are needed for this.

>       There is a typo--s/32784/32783

Wait.. something doesn't add up. The text says "last value and
preceding 32767 values". That makes a total of 32768 values.
Now 0...15 = 16 values and 32784...65535 is 32752. This is
32768 values in all. Am I missing something?

>    make the mistakes easily.

Agree. Suggested text: "The home agent MUST NOT respond to
Neighbor Solicitations sent to its own address when the Source
Address of the solicitation is a home address of a mobile node
for which the home agent has a Binding Cache entry."

>    4. HA looks up the BCE to respond with error

Agree.

>              H bit (0/1) in successive BUs make implementation

I agree. Add text to 9.5.1 where we talk about the conditions
for BUs that use RR as the authz mechanism: "If receiving node
is also acting as a home agent, it does not have a home registration
Binding Cache entry for the given home address." This will lead
to silent discard. Hmm... but wait. This isn't quite sufficient.
It wouldn't work in the order of your example above. Also, following
your order, how does the receiver know in Step 2 that it will act as
a home agent in Step 3? Perhaps it is pre-configured with the home
addresses... but even so, what if there are multiple redundant
home agents? If I register with one of the for H=1, does it imply
that I can do RR with the others, in case they also host a web
server or something?

Jari

---

From: "JinHyeock Choi" <[email-masked]>
Date: Fri, 14 Mar 2003 00:10:38 +0900

Hi Samita

Thanks for good job. I have some comments on Movement Detection.  

>      addresses on its each link.

The more serious problem is that two access routers may have same 
link-local addresses on their different interfaces. Because the uniqueness 
of link-local address is not guaranteed outside a link, we can't avoid 
this problem . 

>      of the mobile's interface) to determine movement at the L3 level.

I wonder it is useful to check link-local address for movement detection. 
Correct me if I am wrong. But I don't see any reason to check link-local 
address in RA for movement detection.   

IMHO, An MN SHOULD NOT use the router address in RA for movement 
detection. If MN is in a network with multiple access routers, it will receive 
the RAs with different router addresses. In this case, even though the router 
address in RA has been changed, a MN has not moved.

On the other hand, because the router address in RA is link-local address, 
its uniqueness is not guaranteed outside a link.  Hence the fact that MN 
receives the RA with the same router address doesn't imply that it still 
remains in the same IP subnet.

I have a question. According to current implementations, when does MN 
send BU? If MN receives a RA with different prefix information, does it 
sends BU immediately or perform NUD with the default router beforehand?

---

From: "JinHyeock Choi" <[email-masked]>
Date: Fri, 14 Mar 2003 00:32:44 +0900

Hi Jari
 
> is delayed until you see also an advertisement. Maybe its the

I see no reason to compare link-local address. Correct me if I am wrong, 
but I think link-local address in RA can play no role for movement detection. 
It gives no information on MN's movement whether MN receives a RA with 
same Router Address or different Router Address. 

Currently there are two proposals to shorten the time to receive a new RA. 
FastRA (draft-mkhalil-ipv6-fastra-03.txt) and FRD (draft-jinchoi-mobileip-frd-00.txt) 

JinHyeock

---

From: Brian Haley <[email-masked]>
Date: Thu, 13 Mar 2003 12:41:36 -0500

> changes are needed for this.

But what if the MN thinks we're an HA, so it sends us a BU (w/IPsec of
course).  In that case we would send a BA w/status 131 (Home registration
not supported).  When I get a BU with the H-bit set, I process it as
in Section 10.3.1, when I get one withoug the H-bit set, I process it as
in Section 9.5.1.  This paragraph from 10.3.1 is pretty clear:

   o  If the node implements only correspondent node functionality, or
      has not been configured to act as a home agent, then the node MUST
      reject the Binding Update.  The node MUST then also return a
      Binding Acknowledgement to the mobile node, in which the Status
      field is set to 131 (home registration not supported).

So which has precedence - our CN/HA configuration or the H-bit?

> 32768 values in all. Am I missing something?

Every implementation has been using a sequence # check similar to this:

#define MIP6_SEQ_GT(s1, s2)     ((short)((s1) - (s2)) > 0)

which now no longer works with the example values in the draft, unless
we add a "- 1". This check is very similar to the TCP sequence # check,
which doesn't have a "- 1" either.

> for which the home agent has a Binding Cache entry."

Is that right?  It doesn't respond to its own address?  Is this
proposed for 11.5.4?

> that I can do RR with the others, in case they also host a web

I'll try and clarify.  What does the receiver do if they have a
binding, and get a BU to update that binding with a different value
in the H-bit field than the current binding?  The MN shouldn't have
sent it since it should know from its binding list what "state" your
binding has, but it did.

-Brian

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 13 Mar 2003 10:32:56 -0800

> sends BU immediately or perform NUD with the default router beforehand?

many implementations follow something called Eager Cell Switching.
a BU is sent immediately with the newCoA as the source address.

Vijay

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 13 Mar 2003 10:28:30 -0800

Jari -

Some feedback...

> and the global addresses come from the PI options?

Or, "just say no" to sending the BU with L=1 ;-)

> Sounds pretty tough for *all* IPv6 routers.

Agreed.

> But we don't have any, do we?

If the link-local scope address of the router is formed from a globally
unique EUI-48 or EUI-64 (it is possible to check the universal/local bit in
the interface ID part of the address to confirm this), then this is a
non-issue. However, that may not always be the case. RFC-2461 is very clear
that the source address of the RA MUST be a link-local scope assigned to the
interface on which the RA is sent, so you can't add some text saying that a
MIPv6-aware router SHOULD use a global scope source address when sending the
RA because that would violate RFC-2461. But, then there is the modified
Prefix Information option containing the router address, see my suggestion
below.

>From RFC-2461:
"A router MAY choose not to include some or all options when sending
   unsolicited Router Advertisements.  For example, if prefix lifetimes
   are much longer than AdvDefaultLifetime, including them every few
   advertisements may be sufficient.  However, when responding to a
   Router Solicitation or while sending the first few initial
   unsolicited advertisements, a router SHOULD include all options so
   that all information (e.g., prefixes) is propagated quickly during
   system initialization."

So, you need to be very careful about how you specify this. Router
Advertisements do not necessarily contain all of the prefix information. If
it is a solicited Router Advertisement, it SHOULD contain all of the prefix
information, but if it is an unsolicited RA, it MAY not. So, I would only
apply this rule to the MN receiving solicited Router Advertisements, in
which case this rule doesn't really add much since most of the RAs received
by the MN will likely be unsolicited. Overall, this seems to be an
architectural problem that may not be easily fixed, without requiring the MN
to do something like frequently solicit its current default router to force
solicited RAs to be returned frequently (i.e. solicited beacons) for this
purpose, which isn't a very nice solution since it is wasteful of both
bandwidth and of the MN's battery power. But, see my suggestion below about
the modified Prefix Information option.

I was also thinking that you could check to see if the source MAC address of
the RA has changed (i.e. when the RA is sent from the link-local scope
address of the current default router), but this is not reliable, since in
the load-balancing case multiple routers having different MAC addresses
would potentially share the same link-local scope router address.

Here's my idea about the modified Prefix Information option:
The MIPv6 specification adds the (R) bit to the Prefix Information option,
and this bit being set indicates that the prefix is actually the address of
the router. Note that it might be site-local scope or global scope, but it
is guaranteed not to be link-local scope. So, it is definitely better than
using a link-local scope address to attempt to uniquely identify a router.
Also, with how the definition of the site-local prefix is being changed so
that it shares the low-order 48 bits (i.e. fec0:xxxx:xxxx:xxxx, the
"xxxx:xxxx:xxxx" part is what I'm referring to) of the prefix with a global
scope prefix assigned to the same link, there is much less potential for
duplicate router addresses on adjacent links when this router address is
site-local scope (this doesn't consider the non-on-link prefix case,
however - i.e. the (L) on-link flag needs to be set in the Prefix
Information Option for this statement to be true). Also, I expect in most
cases when this option is used, the router address it contains is global
scope. So, perhaps just tighten up the rules on this modified Prefix
Information option containing the router address, to say that it MUST be
sent in every Router Advertisement (unsolicited as well as solicited) that a
Mobile IPv6 home agent sends, and that it is RECOMMENDED that the same be
done by other IPv6 routers to better support Mobile IPv6 (i.e. it is hard to
put any kind of requirement on other non-MIPv6-aware IPv6 routers). Also, if
a IPv6 router includes its address in a modified Prefix Information Option
in any Router Advertisement it sends, it MUST send that same modified Prefix
Information Option (as long as that router address is still valid) in all
Router Advertisements that it sends (this allows the MN to check unsolicited
as well as solicited RAs for this information). Note that it is possible for
the router to include more than one router address in the RA using this
modified Prefix Information Option, in which case it MUST include all of
those address (while they are still valid) in each RA it sends (basically,
once it starts advertising a router address this way, it must continue to
advertise that same address as long as it is valid in each RA it sends).
Then, the new mobile node requirements text for this issue becomes something
like:

"If the Router Advertisement sent by the current default router contains the
modified Prefix Information Option with the (R) bit set indicating that it
contains the address of the router and with the (L) on-link flag set
indicating that it can be used for on-link determination, then the mobile
node SHOULD check each Router Advertisement received from that router (both
unsolicited as well as solicited) to verify that it contains the same router
address, and if it does not, then the mobile node SHOULD treat this as an
indication that L3 movement has occurred."

> or should we discuss the other alternatives?

No, as I read this these are not options, this is the entire solution. What
you refer to as solution #1 is actually the first part of the solution, the
other parts are needed as well. So, the MN cannot use RO when sending the
COTI, and also the MN cannot use RO when sending the BU.

> changes are needed for this.

Agreed.

> 32768 values in all. Am I missing something?

Your math looks good.

> for which the home agent has a Binding Cache entry."

Looks good.

> that I can do RR with the others, in case they also host a web

To avoid confusion, I'd require that a node acting as a home agent MUST NOT
respond as a correspondent node on any address on which it is responding as
a home agent. In this case, if the home agent receives a HOTI or COTI
message on one of its home agent addresses requesting it to participate in
the Return Routability procedure, it MUST silently discard the HOTI/COTI
messages and not respond. Note that if it did respond by sending back a
Binding Error status 2 "Unrecognized MH Type value", this could potentially
confuse a MN implementation if the MN is refreshing its home registration
binding at the same time, and cause the MN to mistakenly drop/deregister its
BUL entry for its home registration. So, it is better for the home agent to
just silently discard in this case. I guess the same confusion could occur
in some MN implementations if the home agent were to reply with a ICMPv6
Parameter Problem error code 1 "Mobility Header protocol not supported"
message.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 13 Mar 2003 10:49:27 -0800

> Or, "just say no" to sending the BU with L=1 ;-)

Ed, you got it wrong. here is the real issue. there is a tiny
window when the MN comes home, where both the HA and the MN are
both capable of defending MN's home address. the MN sends a 
deregistration BU. but before the HA responds with a Bind Ack, 
if somebody sends a NS for MN's home address, should the MN 
respond?

it could be the HA itself doing the NS. the HA sends out the NS
when it tries to send the binding ack (it doesnt have a neighbor
cache entry for the MN's home address).

the spec currently says MN should respond to NS from the HA. but
if the HA uses link local address as the source address of the NS,
the MN cant figure out if it is the HA sending the NS or it is
some other node on the home link sending the NS. if the HA uses
its global address as the source address for the NS, the MN can
immediately recognize that it is the HA sending the NS.

IMO, there is no harm in the MN replying to any NS in this tiny
window. it is possible that some node on the home link might get
two Neighbor Advertisments for the MN's home address in this
window. but this is such a rare case, we shouldnt worry about it
at all. we dont have to change any spec if we follow this.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Mar 2003 20:52:30 +0200

> So which has precedence - our CN/HA configuration or the H-bit?

Interesting. What would you propose?

> which doesn't have a "- 1" either.

Ok. But don't we have to say then that "last value and preceding 32768
values" in addition to changing the example value to 32783?

> Is that right?  It doesn't respond to its own address?  Is this

Samita didn't say why this rule would be needed. But my
assumption was: the answer would go to the home agent
itself and not to the sender of the NS.

OTOH, the home agent would drop the NA since it didn't send
any NS, and the end result would be the same. Hmm.... maybe
its better if Samita or someone else from the Connecthathon
would say more about this item and why its needed.

> sent it since it should know from its binding list what "state" your

Ok. That sounds good. So we would add a rule that a BU should not
change the H-bit value in a binding? And if you break the rule,
its a silent discard?

Jari

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 13 Mar 2003 11:07:06 -0800

JinHyeock -

Some feedback below...

> address in RA has been changed, a MN has not moved.

We do NUD of the current default router to make sure that it is still
reachable. If NUD of our current default router fails, then in our MN
implementation we treat that as an indication of L3 movement. This is pretty
much the behavior that is specified for Mobile IPv6 default movement
detection.

Please refer to
http://www.piuha.net./~jarkko/publications/mipv6/issues/issue170.txt
This scenario is not as simple as you might think.

In our MN implementation, we actually filter Parameter Discovery and Prefix
Discovery using the current default router, so our current default router
effectively becomes our virtual link, and when we have to change our current
default router because NUD fails for that router, then we treat moving to a
new router (even if it is on the same physical link) as a L3 move. To
support receiving on the previous primary CoA, we deprecate the prefix
associated with that CoA, and set the valid lifetime very short when we do
the L3 move, and if it isn't included in the prefix information we get in
the solicited RA from the new default router we discover, then it quickly
becomes invalidated, but it stays around long enough to potentially smooth
the link movement process.

The reason why this is difficult is because the scenario of having multiple
routers on the same link, each broadcasting different sets of prefixes
(which is a valid configuration, BTW), is really not very different from the
similar scenario of having overlapping RF coverage areas, and the mobile
node being able to hear multiple routers even though they are actually on
different physical RF links because the mobile node either doesn't have
integration between its RF channel selection and Mobile IPv6 to notify it of
L3 movement and it is bouncing back and forth real fast between the two
different physical RF links (this can happen when the mobile node is
operating on the fringe, and is having difficultly acquiring a RF link that
has acceptable quality and signal strength), or because the RF cells are set
up on the same RF channel so they actually interfere with each other and
overlap coverage areas and bleed together as one apparent super-link when in
fact they are two different physical RF links.

Note that NUD is the only sure way to detect bi-directional reachability of
the default router. Just being able to hear any old router does not mean
that it is bi-directionally reachable; RF is strange that way, the router's
transmissions might be able to be heard by the mobile node, but that doesn't
mean that the mobile node's transmissions can be heard by that same router.

In the scenario described above of overlapping RF coverage areas, one of the
routers that the mobile node is hearing may not be bi-directionally
reachable, while the other router is. In that case, the mobile node should
be using the 2nd router (which is bi-directionally reachable) as its current
default router. Per issue #170, it must only use a primary CoA which is
covered by the prefix information advertised by that router. This guarantees
that when it sends packets using that primary CoA as the source address, its
current default router will recognize the source address of the packet as
being on-link and not discard it due to ingress filtering. Also, it
guarantees that packets sent to it at the primary CoA will be sent through
the router which the mobile node has confirmed to be bi-directionally
reachable.

> remains in the same IP subnet.

Yes, this looks like the real issue here. Note that if the link-local scope
address of the router is formed from a globally unique EUI-48 or EUI-64,
then this becomes a non-issue.

> same Router Address or different Router Address.

It is too bad that the source address of the RA cannot be a global scope
address, but instead MUST be a link-local scope address. However, some
things are possible if we always include a non-link-local scope router
address in the RA (both solicited and unsolicited RAs) using the modified
Prefix Information option, see my other email.

Thanks.
- Ed Remmell
Elmic Systems, USA

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 13 Mar 2003 11:12:43 -0800

Hello Jari,

> change the H-bit value in a binding? And if you break the rule,

It should not be a silent discard.  There should be
an error returned indicating the problem.

Regards,
Charlie P.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 13 Mar 2003 11:19:38 -0800

> would say more about this item and why its needed.

I can give some details. this happens when the MN comes home.

the MN needs a neighbor cache entry for the HA's address before
sending the deregristration BU. currently the spec says

>    Neighbor Solicitation by the mobile node for the home agent's address
>    will normally not be necessary, since the mobile node has already
>    learned the home agent's link-layer address from a Source Link-Layer
>    Address option in a Router Advertisement.  However, if there are
>    multiple home agents it may still be necessary to send a
>    solicitation.  In this special case of the mobile node returning
>    home, the mobile node MUST multicast the packet, and in addition set
>    the Source Address of this Neighbor Solicitation to the unspecified
>    address (0:0:0:0:0:0:0:0).  The target of the Neighbor Solicitation
>    MUST be set to the mobile node's home address.  The destination IP
>    address MUST be set to the Solicited-Node multicast address [3].  The
>    home agent will send a multicast Neighbor Advertisement back to the
>    mobile node with the Solicited flag (S) set to zero.  In any case,
>    the mobile node SHOULD record the information from the Source
>    Link-Layer Address option or from the advertisement, and set the
>    state of the Neighbor Cache entry for the home agent to REACHABLE.
> 

but at Connectathon some mobile node implemenations didnt do this. 
instead they send a NS (src=MN_HoA, dst=HA, target=HA). some home 
agent implmenations respond to this, because they dont check the 
source address of the NS against the proxy neighbor cache (no spec
says you should and you shouldnt, IMO).

Samita is asking for this check.

there is more. section 11.5.4

>    When sending this Binding Update to its home agent, the mobile node
>    must be careful in how it uses Neighbor Solicitation [12] (if needed)
>    to learn the home agent's link-layer address, since the home agent
>    will be currently configured to intercept packets to the mobile
>    node's home address using Duplicate Address Detection (DAD).  In
>    particular, the mobile node is unable to use its home address as the
>    Source Address in the Neighbor Solicitation until the home agent
>    stops defending the home address.

going by this paragraph, the MN shouldnt be sending the NS 
(src=MN_HoA, dst=HA, target=HA).

maybe nothing needs to be changed in the spec. (?)

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 13 Mar 2003 11:22:52 -0800

> an error returned indicating the problem.

Charlie,

it is a bug in the MN implementation if it didnt compare the 
flags in the current BU with the previous BU sent to the same 
CN/HA. do we need an error message?

Vijay

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 13 Mar 2003 11:18:58 -0800

Vijay -

Hmmm... thanks, I'm not sure what I was thinking. Perhaps I was thinking
that I would send the deregistration BU using the link-local scope address
of the MN (since I register with L=0, I can still freely use that address
when I return to home, the HA is not defending it). But then the
specification (and the IPsec security policies) require that I send the
deregistration BU with the source address being the home address. Is it
possible for me to send the deregistration BU with the source address being
my link-local scope address but using the Home Address destination option?
If so, I'd prefer to do it that way, so I can avoid this other requirement
about who I can and can't respond to w/ regards to the NS targeting my home
address.

> at all. we dont have to change any spec if we follow this.

The MN is deregistering at this point in time anyways.

Thanks.
- Ed

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Vijay
> Devarapalli
> Sent: Thursday, March 13, 2003 10:49 AM
> To: Ed Remmell
> Cc: Jari Arkko; Samita Chakrabarti; [email-masked]
> Subject: Re: [mobile-ip] Connectathon 2003 issues for MIPv6 draft-20
>
>
> Ed Remmell wrote:
> >
> > Jari -
> >
> > Some feedback...
> >
> > > > 1. HA De-registration
> > > >

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 13 Mar 2003 11:32:27 -0800

> my link-local scope address but using the Home Address destination option?

you should be able to do this. but remember you cant set the 
L bit to 1, if you use this method.

Vijay

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 13 Mar 2003 12:40:04 -0800

Hello Vijay,

> CN/HA. do we need an error message?

The alternative is that the benighted MN will just keep trying!

Regards,
Charlie P.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Mar 2003 22:46:19 +0200

> Samita is asking for this check.

Ok.

> maybe nothing needs to be changed in the spec. (?)

So, what we are seeing is an illegal situation, and different
home agents respond in different ways. As far as I can see, the NAs
from some of the home agents -- even if a bit suspicious -- do not
really cause damage. So, perhaps we should not change anything...

Jari

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Mar 2003 12:51:25 -0800 (PST)

> The alternative is that the benighted MN will just keep trying!

   I'm not sure of the exact particulars here, but the
   downside of error messages is that they can open you
   up to DoS attacks if they aren't authenticated... not
   sure if that's the case here.

	Mike

---

From: Brian Haley <[email-masked]>
Date: Thu, 13 Mar 2003 16:00:36 -0500

Jari Arkko wrote:
> > in Section 10.3.1, when I get one without the H-bit set, I process it as

This is why I didn't understand why we put "The Home Registration (H) bit
MUST NOT be set" back in 9.5.1...  If the H-bit is set, we should follow
10.3.1, if not, follow 9.5.1.  Of course the H-bit swap case below needs
to be added too.

Since our HA can also be a CN, I would propose what I just said above -
tell the MN to try someone else since either we're not acting as a HA at
all (code 131), or we're not one for this prefix (code 132).  We will
never do RR for a home binding and silently drop the packet when we
see the H-bit is set.

> values" in addition to changing the example value to 32783?

I don't think so, just the 32783 change...

Well, I'm getting myself more confused the more I look into this.
If 0 (zero) is the current seqno, we should accept 1-32767 as valid,
right (the next 32767) ?  This would make the window 32768, including
the current seqno of 0.

We can just put back the macro example that used to be there so
everyone will behave the same :)

> change the H-bit value in a binding? And if you break the rule,

I would send an error in a BA.  But we do not delete the current
binding, just wait for the MN to respond accordingly since it just
re-synchronized itself with us.

-Brian

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Mar 2003 23:43:23 +0200

> right (the next 32767) ?  This would make the window 32768, including

The text talks about the LE range for the window that includes the last
value. And what I proposed was that the LE window would be the last item plus
32768 previous items, i.e. 32769 values. This leaves 32767 values for
the GT range. So, in your example with 0 as the last received seqno we'd have:

  o valid (gt):		1-32767,	a total of 32767 values
  o invalid (le):	32768-0,	a total of 32769 values

These numbers add up, and match the ones in your macro. Or?

Jari

---

From: Brian Haley <[email-masked]>
Date: Thu, 13 Mar 2003 17:30:13 -0500

> These numbers add up, and match the ones in your macro. Or?

Yes, they seem to:

32768 > 0: 0 (false, bad seqno)
32767 > 0: 1 (true, good seqno)

This is why I'm not a math teacher...

-Brian

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 13 Mar 2003 14:38:18 -0800

Jari -

(summarized from my prior lengthy email...)

> is delayed until you see also an advertisement. Maybe its the

Unsolicited RAs MAY not contain all of the prefix information.

Here's my idea about using the modified Prefix Information option for this:

the router. So, perhaps just tighten up the rules on this modified Prefix

Thanks.
- Ed

---

From: Greg Daley <[email-masked]>
Date: Fri, 14 Mar 2003 09:44:43 +1100

Vijay, just an addition.

> at all. we dont have to change any spec if we follow this.

It's important to note that the MN arriving home will
be able to send its NA with O bit set. this will override
the existing HA NA, which will be using proxy-ND (O bit cleared).

There is really no problem with both the HA and the MN sending
the NA to anyone, since the MN wins any ND contest.

Greg D.

---

From: "JinHyeock Choi" <[email-masked]>
Date: Fri, 14 Mar 2003 07:49:12 +0900

Vijay wrote 

> a BU is sent immediately with the newCoA as the source address.

Thanks for your kind reply. Correct me if I am wrong. But I am afraid 
that Eager Cell Switching may cause security problem.

Our MIPv6 implementation sends BU just after it receives a new RA with 
different Prefix Information Option. We found that a single attacker with 
a bogus RA can wreak on havoc.  

For test, we put an attacker and made it advertise a false RA with bogus 
Prefix Information Option at regular interval. Then our MNs just keep sending 
BUs whenever new RA arrives. 

We can fix this by using NUD but NUD takes time. Hence seamless handoff 
is difficult. SEND may provide some solution but we can't be sure. 

We still didn't find the solution suitable for seamless handoff. Anybody in the 
know, kindly let me know.

JinHyeock

---

From: Jari Arkko <[email-masked]>
Date: Fri, 14 Mar 2003 01:06:02 +0200

> is difficult. 

Well, ND at this time is pretty insecure. The only good thing about
its security is that the attacker generally has to be present on the
link and not on the other side of the Internet.

I don't believe NUD vs. RA makes a significant security difference.
If you trust NUD, perhaps a spoofed NA will get the host to switch
to a wrong link-layer address, then just drop answering....

Jari

---

From: "JinHyeock Choi" <[email-masked]>
Date: Sat, 15 Mar 2003 00:48:03 +0900

Ed

Thanks for your thorough mail. It helped to clarify my thought.

Correct me if I am wrong but it seems there is ambiguity on 
Movement Detection (at least to me till now). In L3 movement, 
there happen two incidents.
1) Current default router changes.
2) Current CoA becomes invalid. 

Usually 1), 2) happen at the same time. But not always. 

Hence, for movement detection, MN should check  
i) the reachability of current AR and
ii) the validity of current CoA.

I wonder that it is wise to identify the reachability of current access 
router with the validity of current CoA.

IMHO, it seems safer to me to check i), ii) separately. For i), MN should 
perform NUD with Router Address. But for ii), MN should check the Prefix 
Information Options in RA.   

Here are some of my comments.

> much the behavior that is specified for Mobile IPv6 default movement
 
I wonder how long it takes to detect movement in your implementation? 
If you provide some number, it will help me a lot. According to CTIE implementation, 
without any optimization scheme, it takes several hundreds ms. 
 
> This scenario is not as simple as you might think.

Thanks for notifying this. 
 
> the default router. Just being able to hear any old router does not mean

You are right but the problem is that NUD takes time. I wonder we can support 
seamless handoff with NUD.     
  
> Prefix Information option, see my other email.

I agree that global scope router address will help to check the reachability of 
default router. It may also help to check the validity of CoA using prefix life time.  
 
> Elmic Systems, USA

Another thanks for your kind feed back. 

JinHyeock 

Samsung AIT

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 14 Mar 2003 10:41:01 -0800

JinHyeock -

Please see my comments inline below...

> Usually 1), 2) happen at the same time. But not always.

Yes.

> Information Options in RA.

The primary CoA that you are using to register mobility bindings must be in
the list of prefixes advertised by the current default router. When you move
away from that router because it is no longer reachable, you must invalidate
any prefixes you are still maintaining (and their associated CoAs) that are
not in the set of prefix information advertised in the solicited RA by the
new router that you discover because you can assume that they are now
off-link.

So:
1) determine current default router is unreachable
2) solicit for new default router by sending RS
3) discover new router by receiving solicited RA, invalidate all prefixes
(and associated CoAs) not advertised in solicited RA.

> without any optimization scheme, it takes several hundreds ms.

Yes, well we aren't done implementing Mobile IPv6 mobile node, actually my
mobile node design won't be completed until next week some time. In my
experience, IPv6 NUD takes approx. 45 seconds to determine that a neighbor
is no longer reachable, when data is actively being exchanged with the peer.
I agree this can be a long time. However, if you have some indication first
that the neighbor might be unreachable, and then immediately force NUD into
the PROBE state for that neighbor (and start actively probing by sending
NS), then determination that the neighbor is unreachable actually can happen
much faster, i.e. approx. 3 seconds (for the 3 NUD probes that are sent). L2
triggers can be used to force NUD to enter the PROBE state. I'm not
necessarily referring to the kind of L2 triggers where the network sends
special messages over IP to the mobile node to provide movement information,
just knowledge of basic link movement events (i.e. link up after a
corresponding link down) can help speed up this process by causing the
mobile node to start actively probing the current default router sooner
(with NS, per NUD). Also, you can use the Advertisement Interval option in
the Router Advertisement, if it is available, to speed this up; for example,
if your current default router is frequently sending "beacons" (i.e. very
frequent sending of unsolicited RAs per a specified Advertisement Interval),
the mobile node could decide that the current default router is not
reachable after not receiving some number of the expected unsolicited RA
beacons in sequence, for example if 4 expected beacons are not seen in
sequence then force NUD into the PROBE state and start actively probing. The
time between these beacons can be as short as  0.07 seconds (the current
minimum allowed value for MaxRtrAdvInterval). So, in this case you could
detect a L3 move in less than half a second. Pretty fast. That's assuming
you completely skip NUD probing - the specification says you should still do
NUD probing of the default router in this case, specifically in section
11.5.1 "Movement Detection":

"If the above means do not provide indication that the mobile node is
   still reachable from its current default router (for instance, the
   mobile node receives no packets from the router for a period of
   time), then the mobile node SHOULD attempt to actively probe the
   router with Neighbor Solicitations, even if it is not otherwise
   actively sending packets to the router."

I personally think that in the case of listening for unsolicited RA beacons
per the Advertisement Interval, you can skip the NUD probing. The next
message you send will be a RS, since you assume a L3 move in this case. You
haven't invalidated any prefixes or CoAs yet, you'll do that after you
receive the solicited RA if they aren't advertised in the next solicited RA.
At least that's my plan for implementing this.

> seamless handoff with NUD.

When combined with the other mechanisms mentioned above, you could perhaps
shorten the time needed to detect a L3 move down to approx. 10 seconds,
perhaps less. In the case of using the Advertisement Interval, I'd think
that you might even be able to skip the NUD PROBE state and after missing
receiving some number of beacons in sequence from your current default
router, immediately decide that the current default router is unreachable
and solicit by sending a RS to find a new one, that could be even faster
than 5 seconds (depending on how fast the beacons are being sent).

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

---

From: "JinHyeock Choi" <[email-masked]>
Date: Sat, 15 Mar 2003 12:06:32 +0900

Ed

Thanks for prompt feedback. 
 
> (and associated CoAs) not advertised in solicited RA.

I am afraid step 1), 2) takes too much time for seamless handoff. According 
to ND, MN and access router should execute Random Delay when sending RS 
and solicited RA (maximally 1 and 0.5 sec respectively). 

Are 1), 2) absolutely necessary? I have to think it over more carefully but, 
with some modification, we may find a way to discover new router by receiving 
suitable unsolicited RA.  
  
> At least that's my plan for implementing this.

What do you think of the case that MN receives an unsolicited RA with different 
Prefix Information Option? Can we skip NUD probing? 

IMHO, the relationship between NUD, RA and Movement Detection needs more 
thorough investigation.  
 
These are my quick comments. (I have to catch a plight to SF in hours :-)) I wish 
we talk more about this in SF. 

Best regards

JinHyeock

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 14 Mar 2003 19:54:36 -0800

> Prefix Information Option? Can we skip NUD probing?

No.  Just because the mobile node hears another router advertising different
prefixes, doesn't mean that it should switch from its current default router
(which it has already confirmed via NUD to be bi-directionally reachable).
With RF, hearing another router doesn't mean it is bi-directionally
reachable. Only something like NUD can determine if a router is
bi-directionally reachable. The RS/solicited RA combo is also a pretty good
indicator of bi-directional reachability. Unsolicited RA is not a good
indicator.

I'll talk to you more about this at the IETF meeting, if you'd like.

Thanks.
- Ed

---

From: Jari Arkko <[email-masked]>
Date: Sun, 16 Mar 2003 18:34:25 +0200

> never do RR for a home binding and silently drop the packet when we

Let me try to make sure we see this the same way. The following
table gives the action of a CN upon receiving a BU protected
with none/RR/IPsec with H=0/1:

Case                          Action
----------------------------------------------
H=0, none                     Silent discard (missing RR)
H=0, RR                       Process, send BA with Status=0
H=0, IPsec                    Silent discard (missing RR)
H=1, none                     Silent discard (missing IPsec)
H=1, RR                       Silent discard (missing IPsec)
H=1, IPsec                    Process, send BA with Status=131 or 132

Is this correct or did you want some entries in a different way?
Lets try to agree on this table first, then figure out the text
changes necessary.

Jari

---

From: Brian Haley <[email-masked]>
Date: Mon, 17 Mar 2003 17:47:26 -0500

> with none/RR/IPsec with H=0/1:

That table seems correct.

As long as we make it clear that if H=1, the packet must be IPsec
protected, if H=0, it must be RR protected - there is no other way for
the base draft.  To answer a previous question - the H-bit would seem
to have precedence over the current configuration status (CN/HA) of
the system.

Sorry for the late response...

-Brian