Subject: [nemo] Design Team draft for NEMO Basic Solution

From: "T.J. Kniveton" <[email-masked]>
Date: Mon, 23 Jun 2003 10:59:11 -0700

The NEMO Basic Solution Design Team is pleased to announce the NEMO Basic
Support Protocol draft. After the last few months of work by Vijay, Ryuji,
Alexandru, and Pascal (and some help from Thierry and myself), we would like
to share the results with the larger WG audience and open it up for comments
and suggestions.

You may download the draft from
http://people.nokia.net/vijayd/draft-ietf-nemo-basic-support-00.txt

Thanks,

TJ, Thierry, & NEMO DT

---

From: Chan-Wah Ng <[email-masked]>
Date: 24 Jun 2003 12:19:51 +0800

> http://people.nokia.net/vijayd/draft-ietf-nemo-basic-support-00.txt

I applaud the efforts of the design team on coming up with the initial
version of the basic solution.  Some clarifying questions and cosmetic
comments follow.

o Conceptual clarifications:

In [Section 4.1, page 10, Mobile Router Flag], it is said that the Home
Agent should not forward packets destined for mobile network if R flag
is not set. So, does this means that for a static route configuration
where the next hop for the Mobile Network Prefix is the Mobile Router,
the Home Agent should discard packets sent to the Mobile Network Prefix
if it receives a BU from Mobile Router with R=0?  Perhaps the response
of the Home Agent in this case can be specified?

In [Section 5.1, page 14], it is said that the Binding Update List
should hold the prefix information.  For a MR with multiple prefixes,
are all these prefixes going to be stored in the Binding Update List? 
So each entry in the Binding Update List is going to be dynamic in size
(since the maximum number of prefixes is not known)?

Nothing is said about the Data Structure of the Home Agent. Shouldn't
there be changes to the Binding Cache as well?

Nothing is mentioned about the Home Agent performing ND proxy for the
Mobile Network Prefix. Is it deemed not necessary by the design team?

Nothing is mentioned in the operation of Mobile Router about checks on
received tunnelled packets from Home Agent.  Shouldn't the Mobile Router
verify that the inner packet has a destination address that is within
its Mobile Network Prefix?

o Some cosmetic comments:

In [Section 3, page 8, middle paragraph], the abbreviation CN is used
without explanation, while in the rest of the section, Correspondent
Node is always used in full.

In [Section 4.1, page 10, the explanation of Mobility Options], "... in
addition to what is defined [1]...", perhaps it should read "... in
addition to what is defined in [1]..."?

In [Section 4.3, page 12, and Section 4.4, page 13], perhaps the
explanation of the "Reserved" field should follow the style of IPv6, and
MIPv6, something like: "This field is unused for now.  The value MUST be
initialized to zero by the sender, and MUST be ignored by the receiver".

In [Section 4.4, page 13], the explanation of Prefix Length field seems
to be questionable.  It says "length of the IPv6 prefix contained in the
option", but there is no prefix in this option.  Also, a full-stop
punctuation is missing.

In [Section 5, page 14, right at the bottom], "Similarly to a Mobile
Host, ..." should be "Similar to a Mobile Host, ...".

In [Section 5.4, page 16-17], there are a few instances of the term
"should" is used without capitalization.  In addition, a few instances
of the expression "... Mobile Router will discard ...".  The "will"
should be changed to "MUST", "SHOULD", etc as described in RFC2119.

In [Section 5.4, page 17, right at the top], " ... MAY try try ..." =>
duplicate 'try'.

In [Section 7, page 24, 2nd paragraph], a full-stop punctuation is
missing for the first bullet.

In [Section 7, page 25, 2nd paragraph], "- An Mobile ..." => "- A Mobile
..."

In [Section 7, page 25, 3rd paragraph, first bullet], "... for a MNLP
based ...".  Pardon my ignorance, but I am not familiar with the
abbreviation MNLP.  Perhaps it should be expanded or referenced?

In [Section 7, page 25, 2nd paragraph, 2nd bullet], full-stop
punctuation is missing.

Throughout Sections 5 and 6, the terms "Home Agent", "Mobile Network",
and "Mobile Network Prefix" are sometimes used with all lower case,
sometimes used with first letter capitalized.  It will be nice to be
consistent.

That's all for now, I am still digesting the draft.

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: 24 Jun 2003 12:19:51 +0800

/rgds
/cwng

---

From: Brian Haley <[email-masked]>
Date: Mon, 23 Jun 2003 15:19:53 -0400

I have a comment on the draft regarding Proxy Neighbor Disovery on the Home 
Agent.  The base MIPv6 draft talks about sending Neighbor Advertisements (in 
10.4.1):

   The Router (R) bit in the Advertisement MUST be set to zero.

I would assume you would want to add text in this draft to override that 
behavior when the R-bit is set in the Binding Update since the node really is a 
router.

-Brian

---

From: Brian Haley <[email-masked]>
Date: Mon, 23 Jun 2003 15:19:53 -0400

-Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Jun 2003 12:21:04 +0200

Brian Haley wrote:
> I have a comment on the draft regarding Proxy Neighbor Disovery on 
> the Home Agent.  The base MIPv6 draft talks about sending Neighbor 
> Advertisements (in 10.4.1):
> 
> I would assume you would want to add text in this draft to override 
> that behavior when the R-bit is set in the Binding Update since the 
> node really is a router.

Yes, that is one distinguishing feature of a Home Agent supporting
Mobile Routers (not only Mobile Hosts), and should appear in the draft
in the section Home Agent Operation.

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Jun 2003 12:21:04 +0200

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Jun 2003 14:53:23 +0200

Chan-Wah Ng wrote:
> In [Section 4.1, page 10, Mobile Router Flag], it is said that the 
> Home Agent should not forward packets destined for mobile network if
>  R flag is not set. So, does this means that for a static route 
> configuration where the next hop for the Mobile Network Prefix is the
>  Mobile Router, the Home Agent should discard packets sent to the 
> Mobile Network Prefix if it receives a BU from Mobile Router with 
> R=0?  Perhaps the response of the Home Agent in this case can be 
> specified?

Good issue, should be discussed.  Remark it has implications on many things;

>  are all these prefixes going to be stored in the Binding Update 
> List? So each entry in the Binding Update List is going to be dynamic
>  in size (since the maximum number of prefixes is not known)?

Good issue, same.

>  there be changes to the Binding Cache as well?

I suppose that not even when the Explicit mode is used (prefixes in the
BU) there is no need to modify the Binding Cache of HA.

>  Mobile Network Prefix. Is it deemed not necessary by the design 

I personally think that there is a strong need for such a section in the
Home Agent Operation, but that section should only contain the list of
enhancements of the HA for Mobile Routers.

> Nothing is mentioned in the operation of Mobile Router about checks 
> on received tunnelled packets from Home Agent.  Shouldn't the Mobile
>  Router verify that the inner packet has a destination address that
> is within its Mobile Network Prefix?

Good issue.  It is true that the HA has some ingress filtering language
so the MR should have that too.

Care should be taken here, though.  It is difficult to talk about _the_
"inner" packet because there could be several levels of encapsulation.

>  Node is always used in full.

Ok.

> In [Section 4.1, page 10, the explanation of Mobility Options], "...
>  in addition to what is defined [1]...", perhaps it should read "...
>  in addition to what is defined in [1]..."?

Ok.

> In [Section 4.4, page 13], the explanation of Prefix Length field 
> seems to be questionable.  It says "length of the IPv6 prefix 
> contained in the option", but there is no prefix in this option.

Good issue.  (how about this:

   8 bit unsigned integer indicating the number of bits, when counted
   left to right (or most significant to least significant) of the Home
   Address, that constitute the mobile network prefix.)

> Also, a full-stop punctuation is missing.

Ok.

> Host, ..." should be "Similar to a Mobile Host, ...".

Ok.

> "should" is used without capitalization.  In addition, a few 
> instances of the expression "... Mobile Router will discard ...". The
>  "will" should be changed to "MUST", "SHOULD", etc as described in 
> RFC2119.

Ok all.

> In [Section 5.4, page 17, right at the top], " ... MAY try try ..." 
> => duplicate 'try'.

Ok.

> missing for the first bullet.

Ok.

> In [Section 7, page 25, 2nd paragraph], "- An Mobile ..." => "- A 
> Mobile ..."

Ok.

> abbreviation MNLP.  Perhaps it should be expanded or referenced?

Ok, it's Mobile Network Prefix Length option.

> In [Section 7, page 25, 2nd paragraph, 2nd bullet], full-stop 

Ok.

> Throughout Sections 5 and 6, the terms "Home Agent", "Mobile 
> Network", and "Mobile Network Prefix" are sometimes used with all 
> lower case, sometimes used with first letter capitalized.  It will be
>  nice to be consistent.

Ok how about lower case "mobile network" for "Mobile Network" alone, but
still use "Mobile Network" when suffixed by Prefix Option, or when in a
field of a Binding Ack.

> That's all for now, I am still digesting the draft.

Hope it's easily digestible,

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Jun 2003 14:53:23 +0200

Good issue, same.

Ok.

Ok.

Ok.

Ok.

Ok all.

Ok.

Ok.

Ok.

Ok.

Alex
GBU

---

From: MATSUMOTO Taisuke <[email-masked]>
Date: Tue, 24 Jun 2003 23:52:35 +0900

Dear Alex, Chan-Wah and all,

I'm most grateful for the efforts of the design team.

At Tue, 24 Jun 2003 14:53:23 +0200,
> enhancements of the HA for Mobile Routers.

I'm sorry but I can't imagine the necessity of ND proxy on HA.

When the border router (BR) of the home link has the entry which 
contains the HoA of the MR as the next hop of the Mobile Network 
Prefix, the BR may perform the Neighbor Solicitation. And then 
HA will answer with the proxy Neighbor Advertisement. But I think 
it is a Mobile IP specific, not a NEMO specific, isn't it?

Is there another kind of ND proxy on HA?

***

I found one typo in the section 5.6. page 18. In the 4th line of 
the 3rd paragraph, the word 'visisted' may be 'visited'.

Best regards,
Taisuke
-- 
Taisuke Matsumoto <<Matsushita Electric Industrial Co., Ltd.>>

---

From: MATSUMOTO Taisuke <[email-masked]>
Date: Tue, 24 Jun 2003 23:52:35 +0900

***

Best regards,
Taisuke

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Jun 2003 17:32:55 +0200

MATSUMOTO Taisuke wrote:
>> I personally think that there is a strong need for such a section 
>> in the Home Agent Operation, but that section should only contain 
>> the list of enhancements of the HA for Mobile Routers.
> 
> 
> Prefix, the BR may perform the Neighbor Solicitation. And then HA 
> will answer with the proxy Neighbor Advertisement.

Ok. I think Brian mentioned that the 'R' bit should be set in this NA,
when it corresponds to a Home Address whose Binding Cache entry
corresponds to a received BU that had the 'R' bit set.

More specifically, Mobile IPv6 HA says in the "Intercepting" section
10.4.1 that:

    o  The Router (R) bit in the Advertisement MUST be set to zero.

So, it is probably not very logic for a HA that is itself a router and
moreover sends NA's on behalf of a router, to keep that bit set to zero.

(Also, maybe it is good for the respective Binding Cache entry at the
HA to probably have an additional 'R' bit to ease implementation.  I
think someone raised this issue recently.)

> But I think it is a Mobile IP specific, not a NEMO specific, isn't 
> it?

So you think that probably this should be suggested to the Mobile IP
Working Group instead of the NEMO Working Group?  I guess that can only
be a good alternative.

> Is there another kind of ND proxy on HA?

Please be more specific with the question?

What do you think?

> I found one typo in the section 5.6. page 18. In the 4th line of the 
> 3rd paragraph, the word 'visisted' may be 'visited'.

Ok.

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Jun 2003 17:32:55 +0200

What do you think?

Ok.

Alex
GBU

---

From: Chan-Wah Ng <[email-masked]>
Date: 25 Jun 2003 10:44:40 +0800

Hello, Alex,

> BU) there is no need to modify the Binding Cache of HA.

Why wouldn't the HA want to store the prefixes into the BCE?
Anyway, the R bit should be added to BCE.

> enhancements of the HA for Mobile Routers.
I will comment on this on the other fork of this thread.

> Hope it's easily digestible,

:)

/rgds
/cwng

---

From: MATSUMOTO Taisuke <[email-masked]>
Date: Wed, 25 Jun 2003 10:57:45 +0900

Dear Alex,

On Tue, 24 Jun 2003 17:32:55 +0200,
> moreover sends NA's on behalf of a router, to keep that bit set to zero.

Now I get it. I failed to notice of 'R' bit in NA.

> think someone raised this issue recently.)

I agree.

> Working Group instead of the NEMO Working Group?  I guess that can only

In my previous mail, I was convinced that what is necessary is just to
perform ND proxy as description of Mobile IP.

But I'm clear now. I agree with you on the necessity of discussion about
the HA operations.

> Please be more specific with the question?

Sorry. I had thought that the description in the Mobile IP draft was
enough to specify the behavior of ND proxy on HA. Therefore I wondered
if there were other ND proxies, for instance proxy RS, proxy RA....

Thank you for your kind guidance.

BR,
Taisuke

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 24 Jun 2003 14:33:08 -0700

hi Chan-Wah,

thanks for the detailed comments.

Chan-Wah Ng wrote:
> is not set. 

if the Mobile Router set the R bit to 0 in the Binding
Update, it means it is going to behave as a mobile host.

> So, does this means that for a static route configuration

even in static route configuartion, the HA must 
consult the binding cache for the MR's current CoA.
if there is no binding cache entry, then the packets
are sent on link. if there is a binding cache entry
and the R bit set to 0, the HA must not forward the 
packets.

is this an acceptable solution?

> are all these prefixes going to be stored in the Binding Update List?

yup. it would be a prefix list.

> (since the maximum number of prefixes is not known)?

it is a conceptual data structure. you can implement
it any way you want.

> there be changes to the Binding Cache as well?

yes. you are right. the HA should store the prefixes 
that was sent in the Binding Update. it needs this list
of prefixes later on to delete all the routes, if the
binding cache entry expires. I will add some text.

> Mobile Network Prefix. Is it deemed not necessary by the design team?

it should do the same as described in MIPv6. in addition
it should set the R bit to 1. that is missing. we will
add some text.

> its Mobile Network Prefix?

it should perform all the necessary checks when 
decapsulating and forwarding packets. we will add some
text.

> initialized to zero by the sender, and MUST be ignored by the receiver".

done.

> option", but there is no prefix in this option.  Also, a full-stop

changed it to

	8 bit unsigned integer indicating the prefix length of the 
	IPv6 prefix from which the Home Address included in the 
	Binding Update was configured from.

> That's all for now, I am still digesting the draft.

thanks, once again.

Vijay

---

From: MATSUMOTO Taisuke <[email-masked]>
Date: Wed, 25 Jun 2003 10:57:45 +0900

Dear Alex,

I agree.

BR,
Taisuke

---

From: Mattias Pettersson <[email-masked]>
Date: Thu, 26 Jun 2003 09:34:00 +0200

I think you have produced a good I-D that manages to clear out the 
worries I had with static/dynamic routing, and BC and routing table 
interaction.

I support this solution. Well done!

The only comment I have is regarding section 7 and the associated 
terminology: it is difficult to understand what you mean. Can you 
explain it further, maybe with an example? Personally, I will have to 
read it again.

BR
/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Thu, 26 Jun 2003 09:34:00 +0200

BR
/Mattias

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Jun 2003 14:53:26 +0200

> Anyway, the R bit should be added to BCE.

Ok, this is one case in point where I change my mind every now and
then.  It is possible
to have the prefixes in the BC, as well as it is possible to keep the
prefixes in
the Prefix Table only.   My oppinion only.

Just need to figure out how to best operate them.

If one prefers the prefixes in the BC of HA, one needs to also consider
the consequences of the later eventual temptation to use same BC at CN.

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Jun 2003 14:53:26 +0200

Alex
GBU

---

From: Chan-Wah Ng <[email-masked]>
Date: 25 Jun 2003 10:44:40 +0800

Hello, Alex,

:)

/rgds
/cwng

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 24 Jun 2003 14:33:08 -0700

hi Chan-Wah,

done.

changed it to

thanks, once again.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 26 Jun 2003 16:47:20 -0700

hi Brian,

you are right. here is some text

   The Home Agent defends the Mobile Router's home address through Proxy
   Neighbor Discovery.  When the Home Agent sends a proxy Neighbor
   Advertisement for the Mobile Router's Home Address, it MUST set the
   Router flag 'R' to 1 [9].  The Router flag MUST not be set, if the
   Mobile Router had sent a Binding Update with the Mobile Router Flag
   set to 0.

it will go in section 6.2. is this enough?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 26 Jun 2003 16:47:20 -0700

hi Brian,

Vijay

---

From: Chan-Wah Ng <[email-masked]>
Date: 27 Jun 2003 10:54:49 +0800

Hello Matsumoto-san, Alex, and Vijay,

(this mail is a resend since my previous mail did not appear on the list
after a 2 day wait).

Agreed that HA should respond to NS for the HoA of MR.  The response,
NA, should have the R-bit set if the R-bit was set in BU from MR.  (As
mentioned by Brian).

Should HA respond to RS on behalf of MR if the R-bit was set in the BU? 
Regardless of the answer, this need to be explained in the Draft, IMHO.

Should the HA broadcast a RA on behalf of MR if the R-bit was set in the
BU?  Or should the MR send RA broadcast to the home link via the MRHA
tunnel?  I think it was suggested in the Draft that MR may do so,
provided the Lifetime field is set to 0.

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: 27 Jun 2003 10:54:49 +0800

/rgds
/cwng

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 27 Jun 2003 10:20:53 -0700

> Regardless of the answer, this need to be explained in the Draft, IMHO.

RS is typically sent to the all routers multicast address.
it is not sent to a particular address. so there is no 
question of HA responding to an RS on MR's behalf. and
anyway this information is useless.

> BU? 

no. the MR is not on the home link. there is no point.

> Or should the MR send RA broadcast to the home link via the MRHA
> tunnel? 

it could. but the information is useless again. the HA 
cant do anything with it.

> I think it was suggested in the Draft that MR may do so,

this is when the MR is at home and sends a RA on the link
with which it is connected to the home link. the router
lifetime is set to 0, so that no other node configures the
MR as a default router.

Vijay

---

From: Brian Haley <[email-masked]>
Date: Fri, 27 Jun 2003 14:32:03 -0400

Stealing some words from the Mipv6 draft:

     The Home Agent defends the Mobile Router's home address through Proxy
     Neighbor Discovery by multicasting onto the home like a Neighbor
     Advertisement message on behalf of the mobile router.  All fields in each
     such Neighbor Advertisement message SHOULD be set in the same way they would
     be set by the mobile router itself if sending this Neighbor Advertisement
     while at home, as described in [1], with the exception that the Router
     (R) bit in the Advertisement MUST be set to one if the Mobile Router (R)
     flag has been specified in the Binding Update.

Anything close is good enough since implementors will get the point.

-Brian

---

From: Brian Haley <[email-masked]>
Date: Fri, 27 Jun 2003 14:32:03 -0400

-Brian

---

From: Chan-Wah Ng <[email-masked]>
Date: 28 Jun 2003 10:05:15 +0800

> cant do anything with it.
yep, that's right.  I failed to realize that RA broadcast can only be
single hop.

> lifetime is set to 0, so that no other node configures the

Oh, let me check the wording of the draft ... guess I didn't digest the
draft fully, my mistake.

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: 28 Jun 2003 10:05:15 +0800

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: 28 Jun 2003 10:12:58 +0800

Hello Vijay,

> is this an acceptable solution?
Yes, it is.  I just thought that this should be reflected in the draft.

> it is a conceptual data structure. you can implement
That's perfectly fine.  So apart from the theoretical limit due to
maximum allowed IPv6 packet size, there is no limit on the number of
prefixes, am I correct?

> binding cache entry expires. I will add some text.
OK.

> it should set the R bit to 1. that is missing. we will
Let me think about the consequence of HA not doing RA proxy for MR.
  
> decapsulating and forwarding packets. we will add some
OK

> 	Binding Update was configured from.
Looks fine.

/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: 28 Jun 2003 10:12:58 +0800

Hello Vijay,

OK.

OK

Looks fine.

/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: 28 Jun 2003 10:22:55 +0800

Hello Alex,

> the Prefix Table only.   My oppinion only.

I need to look into this more carefully.  The worry on my mind when the
prefixes is not in the BCE is that certain prefix routes in the Prefix
Table may get stale, or deleted accidentally, when we consider
multi-homed mobile network where more than one mobile router handles the
same mobile network prefix.

> the consequences of the later eventual temptation to use same BC at CN.

Good point.  Especially when one consider the possibility of HA itself
being a CN to some other mobile nodes.

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: 28 Jun 2003 10:22:55 +0800

Hello Alex,

/rgds
/cwng

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 29 Jun 2003 22:49:00 -0700

> maximum allowed IPv6 packet size, there is no limit on the number of

right.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 29 Jun 2003 22:49:00 -0700

right.

Vijay