Subject: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments

From: "Kevin Miles" <[email-masked]>
Date: Mon, 8 Jul 2002 21:37:25 +0100

Various comments on MIPv6 I-D 18.

1. There still appears to be a minor bug in the description 
   of how the DHAAD response is created. The addresses are 
   ordered by decreasing Preference, and if the sender is 
   the first in the list, its address should be omitted and 
   the recipient will assume that the sender is most 
   preferred. But there is also the provision for 
   truncating the response if it exceeds max MTU. So, for 
   example, if the sender is least preferred but its 
   address gets truncated because of MTU size constraints, 
   the recipient will incorrectly assume the sender to be 
   most preferred. Since all this is specified using SHOULD 
   and SHOULD NOT, an implementation can legitimately 
   achieve approximately the intended behaviour by not 
   doing what the I-D says, but the way it is currently 
   described is an invitation to error. An obvious fix is 
   to eliminate the 'bandwidth conservation' and explicitly 
   transmit all addresses that will fit in the response.

2. In section 9.4.1, it says: "If the Home Registration (H) 
   bit is set in the Binding Update, the Binding Update is 
   processed according to the procedure specified in 
   Section 10.2; otherwise, it is processed according to 
   the procedure specified in Section 9.4.2." 
   Unfortunately, the context of this text implies that the 
   Return Routeability procedure can be used to secure a 
   Home Registration, which is not the case. Same problem 
   with the next bullet, too. 

3. Sections 6.1.8 and 9.4.4 are inconsistent. The former 
   says a BA does not use a routing header. The latter 
   describes conditions under which it does.

4. Section 10.3 says "If the home agent does not reject the 
   Binding Update as described above, then it MUST delete 
   any existing entry in its Binding Cache for this mobile 
   node, and proceed as follows." Should "any existing 
   entry" read "all existing entries"? I.e., what are the 
   semantics of the S bit in a deregistration? For example, 
   is it permissible to register a set of addresses using 
   S=0 and then individually deregister them with S=1?

Editorial:

5. The document still has a few instances of "Binding 
   Update option". Most, if not all, should read "Binding 
   Update" or "Binding Update message.

6. Repeated text on p64: "Subsequent checks depend on the 
   particular Mobility Header message, as specified in 
   Sections 9.3 and 9.4.  Subsequent checks depend on the 
   particular Mobility Header message."

Kevin.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 09 Jul 2002 12:06:50 +0300

Thanks Kevin for your comments. I assigned issue #56 for this.

>    transmit all addresses that will fit in the response.

I'm OK with this fix.

>    with the next bullet, too. 

Right.

>    describes conditions under which it does.

I'm confused because 6.1.8 does talk about the routing header.
In any case, I'm suggesting we should delete the duplicate text
from sections 6.1.x and refer to the right place in the rest of
the draft for setting the addresses and headers.

>    S=0 and then individually deregister them with S=1?

I believe S=0 in a registration will create separate entries,
so you should be able to remove them individually. But the draft
is quiet on what semantics S bit has on deregistration. My proposal
is that it should have the same semantics, i.e. that you could also
do a S=0 deregistration to remove all of your bindings.

>    Update" or "Binding Update message.

Thanks. Fixed.

>    particular Mobility Header message."

Fixed.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Jul 2002 10:56:31 -0700

> do a S=0 deregistration to remove all of your bindings.

this is what is done in our implementation. when the HA receives
a deregistration BU with S=0, it removes all bindings for the
corresponding MN.

Vijay

---

From: "Kevin Miles" <[email-masked]>
Date: Wed, 10 Jul 2002 16:05:37 +0100

> a deregistration BU with S=0, it removes all bindings for the
I agree that maintaining consistent semantics for S is most appropriate.

So, at the risk of stating the obvious, the intended behaviour is:-

S=0 achieves the same effect as a set of individual BUs with S=1, one for each
of the MN's home addresses. Each resulting BCE is then operated entirely
independently (own tunnel, with own SAs if necessary), except for subsequent BUs
in which S=0. Given that related BCEs may have been independently created with
S=1, an HA receiving a BU with S=0 (for update or deregistration) decides which
existing BCEs it applies to by matching IIDs alone. (I.e., it doesn't matter if
some BCEs have different CoAs, etc.)

Right?

Kevin.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Jul 2002 11:07:30 -0700

Kevin Miles wrote:

> existing BCEs it applies to by matching IIDs alone. 

if BCEs are created independently, there will be corresponding 
independent entries in the MN's binding update list.

> (I.e., it doesn't matter if

why would the CoA be different? the MN must have updated all bindings
when it changed its CoA.

anyway, in our implementation, the binding cache entries created 
for a BU with S=0 are linked. there are pointers from the BCE
created for the HoA in the BU. I dont have to search all BCEs
with matching IIDs.

Vijay

---

From: "Kevin Miles" <[email-masked]>
Date: Wed, 10 Jul 2002 22:40:55 +0100

> created for the HoA in the BU. I dont have to search all BCEs
So if the BCEs were created independently with S=1, presumably they would not be
linked. In which case, a single deregistration BU with S=0 could not be used to
deregister them. Correct?

This is what I'm trying to get clarified. Is it permissible, under any
circumstances, for the MN to change the value of the S bit in successive BUs
that relate to the same binding(s)? I cannot see anything in the draft that
prohibits it. Currently, it would appear that an MN could use multiple BUs with
S=1 to selectively register certain addresses and then deregister them all with
a single BU with S=0.

As Jari observed, the draft is completely silent on the use of the S bit in
deregistrations and, for that matter, BUs that update an existing registration.

Kevin.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Jul 2002 15:24:28 -0700

> deregister them. Correct?

right (in our implementation).

> prohibits it. Currently, it would appear that an MN could use multiple BUs with

IMO, it would be simpler if the draft prohibits it.

Vijay

---

From: "Kevin Miles" <[email-masked]>
Date: Thu, 11 Jul 2002 09:37:55 +0100

> Kevin Miles wrote:
<snip>
> IMO, it would be simpler if the draft prohibits it.
Works for me.

Kevin.

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Thu, 11 Jul 2002 11:07:26 -0700

1. The requirements for IPv6 routers and nodes would be better addressed
in a separate ID. Similarly the security issues (i.e. BU authentication
etc.) can also be better addressed in a separate ID.
2. A justification for "return routability" as the way it is done with
HoTI/HoT and CoTI/CoT should be there.  Also some details about why both
HoTI and CoTI are needed, rather than just HoTI.
3. The various conceptual data structures in HA, MN, and CN would be
better described through pictures.
4. The BCE of the CN is indexed by the home-address of the MN.  The spec
as it is now allows link-local addresses. So is there a possibility that
two MN's may end up having the same l-l address in a CN?
5. In a hypothetical situation, a MN may visit a foreign network and
acquires the same CoA address and the l-l HoA.  Is it a possibility? Are
CoA's always global?

Subrata

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Kevin Miles
Sent: Thursday, July 11, 2002 1:38 AM
To: 'Vijay Devarapalli'
Cc: 'Jari Arkko'; [email-masked]
Subject: RE: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments

<snip>
Works for me.

Kevin.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 11 Jul 2002 17:10:43 -0700

hi,

> two MN's may end up having the same l-l address in a CN?

I dont understand this. how did the link local address of the MN
reach the CN? a binding cache entry for a link local address would
exist only on a Home Agent. not on the CN.

> acquires the same CoA address and the l-l HoA.  Is it a possibility? Are

yes. they are! the CoA is configured when the MN receives a router 
advert in the foreign network.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Sat, 13 Jul 2002 01:13:21 +0300

Kevin Miles wrote:

> Vijay Devarapalli wrote:
> 
> 
>>Kevin Miles wrote:
>>
> <snip>
> 
>>>This is what I'm trying to get clarified. Is it 
>>>
>>permissible, under any
>>
>>>circumstances, for the MN to change the value of the S bit 
>>>
>>in successive BUs
>>
>>>that relate to the same binding(s)? I cannot see anything 
>>>
>>in the draft that
>>
>>>prohibits it. Currently, it would appear that an MN could 
>>>
>>use multiple BUs with
>>

Works for me too. Let's prohibit it. Also, we need to worry
about the case where the prefixes change between S=0 reg & dereg.
So, my proposal is to define an S=0 dereg as a deregistration of
those addresses that were registered in the original S=0 reg. If no
such original S=0 reg was done, the HA will return a new BA error code.

Finally, in a S=0 rereg we could implicitly dereg all address whose
prefixes have disappeared between the reg & dereg. This appears
unnecessary, though, as the HA would not allow the lifetime to exceed
the prefix lifetimes. But this should be noted in the draft to make it
clear.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 13 Jul 2002 01:47:50 +0300

> etc.) can also be better addressed in a separate ID.

This was at least partially the intention. That is, the IPv6 node requirements
document would list the requirements for particular types of IPv6 nodes. The
intention of section 8 is to summarize the requirements for a particular class
of functionality, such as nodes that support route optimization. I think this
general approach has already been agreed in the WG.

However, we have a number of alternatives on doing this:

1. Have a separate requirements section plus the behaviour sections (as is now)
2. Remove the requirements section, and improve the behaviour sections to make it more
    clear what is mandatory to implement from e.g. correspondent node behaviour and what is
    not.
3. Move the contents of the requirements sections to the corresponding behaviour sections
    as an introduction on what is mandatory to implement.

What do folks on the list feel about these alternatives?

> better described through pictures.

I'd like this, but I'm not sure what we can describe. As it is now, the different

data structures are quite independent from each other. So it's hard to show any
kinds of relationships. And what could we show from the individual data structures
then? We can't really show specific linked-list or hash table structures, all we can
really show is the list of fields in an entry. And for that purpose I believe the text
is already sufficient.

Both items registered as issue #60.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 13 Jul 2002 01:52:42 +0300

> HoTI and CoTI are needed, rather than just HoTI.

14.4.1 talks about some of the background, more can be found from the

referred documents such as draft-aura. Is there something specific that
you are missing there?

Regarding the need for both HoTi and CoTi: we could indeed have just one
initiation message (even if two responses are needed). However, the text
in 14.4.1 about symmetric exchanges applies here... we wanted to make the
protocol symmetric in all requests so that we'd have less problems with
reflection through e.g. the combined hoti-coti message to an unsuspecting
third party.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 13 Jul 2002 02:35:06 +0300

> two MN's may end up having the same l-l address in a CN?

You already had a discussion with Vijay, but I would add the following:

A CN that is on the home link could in theory be able to create a BCE
that points from a ll home address to a global coa. However, there's
a problem in how route optimization could be employed with ll addresses.
Assume the CN uses a link-local address, and adds a RH to a packet destined
to the mobile node's ll address. The source address of this packet would
have to be ll, and the destination would have to be non-ll. This appears
to be against normal source address selection rules.

However, I can't find anything in the draft that prohibits RO with
ll addresses. So my proposal is that we prohibit RO for ll home or
CN addresses. Ok for everyone?

> acquires the same CoA address and the l-l HoA.  Is it a possibility? Are

As Vijay already noted, CoA's are formed from advertised prefixes, which

are never link-local (SHOULD NOT in RFC 2461).

Both items registered as issue #62

Jari
----
P.S. As you may recall, the issue list can be found at:
   http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html
The files on the list will be updated soon.

---

From: "Kevin Miles" <[email-masked]>
Date: Mon, 15 Jul 2002 12:05:26 +0100

> the prefix lifetimes. But this should be noted in the draft to make it
While you're there, you might also want to note the intended DAD behaviour upon
receipt of a S=0 rereg when new prefixes have appeared. Presumably, you DAD and
defend the new addresses when the rereg BU arrives, and not before. That is, you
do not do it immediately the applicable prefixes come into operation. Or do you?

Kevin.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 26 Jul 2002 12:39:02 +0300

>>such original S=0 reg was done, the HA will return a new BA

Updated proposal: If the registration was a S=1 and the de-registration
ues S=0, then this would be allowed and would mean de-registering the
single address originally registered. This will avoid an extra
error code.

> do not do it immediately the applicable prefixes come into operation. Or do you?

I think we should do only after the rereg arrives. Thanks, this also needs
to be clarified.

Jari

---

From: "Kevin Miles" <[email-masked]>
Date: Fri, 26 Jul 2002 16:09:37 +0100

> single address originally registered. This will avoid an extra
Okay. What about the rereg case? Can you 'upgrade' from S=1 to S=0 in successive
registration BUs? It doesn't sound, to me, like a useful thing to be able to do.
But if it's illegal, either we need a suitable error code, or we need to say
that the S bit is ignored in a BU for which there is an existing BCE and treated
as if it had the value of the originating BU.

Kevin.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 26 Jul 2002 21:44:42 +0300

> as if it had the value of the originating BU.

Good point.

Why don't we simply allow this behaviour? The rereg will set up entries for
every current prefix, and will override the entry for the original single
address.

Jari

---

From: "Kevin Miles" <[email-masked]>
Date: Fri, 26 Jul 2002 23:04:18 +0100

> every current prefix, and will override the entry for the
So at any time the mobile can choose to switch from S=1 to S=0? Which begs the
question, can it also switch the other way and manage its set of BCEs
individually? (Isn't this where we came in :-)

I can't actually think why it would be useful for a mobile node to want to
change the value of S in either direction during a single binding. Does anyone
have a reason for allowing this?

My preferred resolution is to declare that the value of S on all rereg and dereg
BUs is ignored and treated as if it were the same as on the original BU. (If the
mobile node really needs to change the value of S, it can always dereg and reg
again.)

Kevin.

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 26 Jul 2002 17:03:18 -0700

> mobile node really needs to change the value of S, it can always dereg and reg

I agree with Kevin.

Vijay