Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Jan 2007 10:43:56 +0100

Vijay Devarapalli wrote:
> Alexandru Petrescu wrote:
>> Vijay Devarapalli wrote:
>>> Mondemu Sreenivasulu-A21119 wrote:
>>>> Sorry, The small correction. It is not very clear from RFC 3775
>>>>  whether it is a expected scenario.
>>> 
>>> RFC 3775 requires the HA to send the Echo Reply back with a 
>>> routing header if the Echo request had the home address option.
>> 
>> Yes, that's fine, 3775 clear on that.
>> 
>> But does 3775 require the _HA_ to send a Binding Error to MN if it
>>  received an EchoReq with DO whose HoA is not in its BC?  The TAHI
>>  certification tests seem to require this.
> 
> No. The Binding Error message is sent only the CN. The TAHI test is 
> valid only if your HA is also a CN.

Ok, so a HA not sending Binding Error to a MN it serves would still be
TAHI-conformant?

>> 3775 does require the _CN_ to do so.  Would HA also send Binding 
>> Errors when EchoReq DO's has a HoA not present its BC?
>> 
>> The 3775 Binding Error text seems to be only about CN, not HA.
>> 
>> This again is a very needed clarification for anybody implementing 
>> an HA.  This clarification is needed together with clarification 
>> whether HA sends Binding Refresh Request or not (3775 says CN 
>> does).
> 
> If your HA implementation is strictly a home agent and does not 
> behave like a CN for a mobile node that it does not serve, then you 
> don't have to implement the Binding Error message.
> 
> If your HA implementation behaves like a CN for a mobile node that it
>  does not serve, then it must send a Binding Error message to the 
> mobile node when it receives a packet with a home address option and 
> there is no corresponding binding cache entry.

Makes sense.  I mean a HA that does serve the MN and that is pinged by
that MN.

Alex

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

---

From: "Mondemu Sreenivasulu-A21119" <[email-masked]>
Date: Wed, 3 Jan 2007 13:32:42 +0800

Hi Vijay & Alex,

HA has to send Binding error message when it gets unrecognized MH type.
Here I am cut and pasting the RFC statement

"o  The MH Type field MUST have a known value (Section 6.1.1).
      Otherwise, the node MUST discard the message and issue a Binding
      Error message as described in Section 9.3.3, with Status field set
      to 2 (unrecognized MH Type value).

Thanks & regards
Sreeni 

-----Original Message-----
From: Petrescu Alexandru-AAP021 
Sent: Tuesday, January 02, 2007 3:14 PM
To: Vijay Devarapalli
Cc: Mondemu Sreenivasulu-A21119; [email-masked]
Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA

Vijay Devarapalli wrote:
>>> RFC 3775 requires the HA to send the Echo Reply back with a routing 
>>> header if the Echo request had the home address option.
>> 

>> This again is a very needed clarification for anybody implementing an

>> HA.  This clarification is needed together with clarification whether

>> HA sends Binding Refresh Request or not (3775 says CN does).
> 
> If your HA implementation is strictly a home agent and does not behave

> like a CN for a mobile node that it does not serve, then you don't 
> have to implement the Binding Error message.
> 

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Jan 2007 22:21:10 -0800

Hi Sreeni,

>       to 2 (unrecognized MH Type value).

You are correct. The HA does send the binding error when
it with status field set to 2. But it does not send a
Binding error with status field set to 1, unless it is
a CN for a mobile node that it does not serve.

We were discussing the HA receiving a data packet with a
home address option with no corresponding binding cache
entry for the home address.

Vijay

---

From: "K.Kawaguchi" <[email-masked]>
Date: Fri, 5 Jan 2007 16:50:52 +0900

Hi,

I am maintaining the TAHI MIPv6/NEMO comformance tool.
If it is necessary, the tool will be corrected.
Please let us confirm some.

1.
The function of CN, HA, and MN is independent. Of course, some node can
have functions(CN+HA, CN+MN). However, the function works alone in the
following cases.

  HA(CN+HA) works as HA for MN that binds home registration.
  CN(CN+HA) works as CN for MN that binds correspondent registration.

After the above-mentioned is based, HA and CN have the same function
part. It is described in CN(section 9) of RFC3775, and is referred to
in HA(section 10).
Is this correct?

2.
In HA(Section 10), BRR is not described. So, HA doesn't send BRR to MN.
HA informs of the binding time with Lifetime or Binding Refresh Advice
mobility option in BA.
Is this correct?

3.
HA might receive the packet with Home Address option from MN. But, in
HA (Section 10), there is no description when the direct packet is
received from MN to HA.
What should HA work ?

An opposite direction is described in 10.4.2 that refer to 9.3.2.

4.
Additionally, if the operation of HA and CN is different.
If (CN+HA) receives packet with invalid home address option, which
operation should (CN+HA) take ?

Best regards
---
Kiyoaki KAWAGUCHI

> Makes sense.  I mean a HA that does serve the MN and that is pinged by

Best regards
---
Kiyoaki KAWAGUCHI

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 08 Jan 2007 17:04:55 +0100

K.Kawaguchi wrote:
> Hi,
> 
> I am maintaining the TAHI MIPv6/NEMO comformance tool. If it is 
> necessary, the tool will be corrected. Please let us confirm some.
> 
> 
> 1. The function of CN, HA, and MN is independent. Of course, some 
> node can have functions(CN+HA, CN+MN). However, the function works 
> alone in the following cases.
> 
> HA(CN+HA) works as HA for MN that binds home registration. CN(CN+HA) 
> works as CN for MN that binds correspondent registration.

I understand, it's a new terminology.

A CN(CN+HA) works as a CN for MN that binds correspondent registration -
yes, it maintains a BC - but it doesn't do proxy ND for that MN.  So one
wouldn't call it CN(CN+HA) because that 'HA' word makes think it is a
complete HA implementation, and a complete HA implementation does proxy ND.

>  part. It is described in CN(section 9) of RFC3775, and is referred
> to in HA(section 10). Is this correct?

Mostly yes, but in detail half far from yes.

Section 10 HA has 3 subsections (out of 6) that are specific parts to
only a HA, and not to a CN.  These HA-specific functions are MPD, DHAAD
and proxyND.

So a CN(CN+HA) does not do MPD, DHAAD nor proxyND; but the HA word in
CN(CN+HA) makes think so.

So I think instead of saying HAHACN binds home registration and HACNCN
binds correspondent registration I think one should list the MH messages
and operations that a HAHACN and a HACNCN should do.

Or maybe you mean HAHACN does all section 10 while
                   HACNCN does only 3 subsections of section 10?

> 2. In HA(Section 10), BRR is not described. So, HA doesn't send BRR 
> to MN. HA informs of the binding time with Lifetime or Binding 
> Refresh Advice mobility option in BA. Is this correct?

I guess so.

But I think it makes sense for a full HA (or HAHACN) to send BRR,
because it is useful when a BC entry expires and the BU is lost.

Current 3775 doesn't seem to say so.

> 3. HA might receive the packet with Home Address option from MN. But,
>  in HA (Section 10), there is no description when the direct packet
> is received from MN to HA. What should HA work ?

Good question.  So text should be added to clarify?

Also, about Binding Error.  Section 9.2 Processing Mobility Headers says
  that _anybody_ processing a received Mobility Header whose Type is not
understood should send a BErr.  That means that a HA should too (not
only a CN); and regardless of whether the originator of that message is
a MN registered to the HA or not registered.

> 4. Additionally, if the operation of HA and CN is different. If 
> (CN+HA) receives packet with invalid home address option, which 

Both HA and CN should be able to build BErr messages.  If the document
doesn't say so then it should.

It is not enough to relegate this behaviour to a single statement in rfc
"A CN can be a HA, or a HA can be a CN, or anybody should be send a
BErr".  It should clearly say "A HA should be able to send BErr".

Alex

---

From: "K.Kawaguchi" <[email-masked]>
Date: Tue, 9 Jan 2007 16:52:42 +0900

Hi,

> complete HA implementation, and a complete HA implementation does proxy ND.

I didn't intend to define its new terminology. What I want to say is
that X(CN+HA) works by either of HA or CN for MN. HA functions and CN
functions are separated. Therefore, I think that a special specification
of X(CN+HA) is unnecessary (The following 4 is excluded).

> and operations that a HAHACN and a HACNCN should do.

I see. I think that Section 9, 10, and 11 of RFC3775 are described by
that intention.

> Current 3775 doesn't seem to say so.

OK, we need the sentence about BRR of HA-MN in RFC.
(MUST,SHOULD,MAY,MUST NOT)

Though this is a personal opinion.
I guesses BRR to be only CN-MN from MN(section 11.7.4) in current RFC3775.
CN and MN are equal in the communication. MN can arbitrarily do binding.
I think that BRR was prepared so that CN may demand.
On the other hand, MN must do binding to HA by own demand. I think that
HA is enough to play a passive role for MN. I think that HA MUST NOT
send BRR.

> Good question.  So text should be added to?

Yes. I agree.
Section like "Section 10.4.x Reciving Packets with Home Address Option"
is necessary for HA(Section 10).

> BErr".  It should clearly say "A HA should be able to send BErr".

I agree.
I think that HA should process the packet w/ Home Address Option and the
BE(status 1) like the first three paragraphs of Section 9.3.1.

Best regards
---
Kiyoaki KAWAGUCHI

Best regards
---
Kiyoaki KAWAGUCHI

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 09 Jan 2007 14:36:23 +0100

K.Kawaguchi wrote:
>>>  node can have functions(CN+HA, CN+MN). However, the function 
>>> works alone in the following cases.
>>> 
>> A CN(CN+HA) works as a CN for MN that binds correspondent 
>> registration - yes, it maintains a BC - but it doesn't do proxy ND
>>  for that MN.  So one wouldn't call it CN(CN+HA) because that 'HA'
>>  word makes think it is a complete HA implementation, and a
>> complete HA implementation does proxy ND.
> 
> functions are separated. Therefore, I think that a special 
> specification of X(CN+HA) is unnecessary (The following 4 is 
> excluded).

Ok. To my reading it is important to list what functionalities a certain
entity implements - in the document.  For example, say that HA(CN+HA)
does proxy ND but a CN(CN+HA) doesn't.  Should be clear from reading
short paragraphs.

>>> After the above-mentioned is based, HA and CN have the same 
>>> function part. It is described in CN(section 9) of RFC3775, and 
>>> is referred to in HA(section 10). Is this correct?
>> Section 10 HA has 3 subsections (out of 6) that are specific parts
>>  to only a HA, and not to a CN.  These HA-specific functions are 
>> MPD, DHAAD and proxyND.
>> 
>> So a CN(CN+HA) does not do MPD, DHAAD nor proxyND; but the HA word
>>  in CN(CN+HA) makes think so.
>> 
>> So I think instead of saying HAHACN binds home registration and 
>> HACNCN binds correspondent registration I think one should list the
>>  MH messages and operations that a HAHACN and a HACNCN should do.
> 
>> Or maybe you mean HAHACN does all section 10 while HACNCN does only
>>  3 subsections of section 10?
>> 
>>> 2. In HA(Section 10), BRR is not described. So, HA doesn't send 
>>> BRR to MN. HA informs of the binding time with Lifetime or 
>>> Binding Refresh Advice mobility option in BA. Is this correct?
>> I guess so.
>> 

I agree the document should say something about HA and BRR, without need
to browse back and forth for hints on whether a CN can be a HA and under
what circumstances.

> Though this is a personal opinion. I guesses BRR to be only CN-MN 
> from MN(section 11.7.4) in current RFC3775. CN and MN are equal in 
> the communication. MN can arbitrarily do binding. I think that BRR 
> was prepared so that CN may demand. On the other hand, MN must do 
> binding to HA by own demand. I think that HA is enough to play a 
> passive role for MN. I think that HA MUST NOT send BRR.

I think it should, personal opinion.

In any case, the document should be clear whether HA sends or not the
BRR.  It's not good to just rely on the fact that sometimes HA can be a
CN for unregistered MNs, because this doesn't say whether HA sends or
not BRR to its registered MNs.

>>> 3. HA might receive the packet with Home Address option from MN.
>>>  But, in HA (Section 10), there is no description when the direct
>>>  packet is received from MN to HA. What should HA work ?
> Yes. I agree. Section like "Section 10.4.x Reciving Packets with Home
>  Address Option" is necessary for HA(Section 10).
> 
> 
>> Also, about Binding Error.  Section 9.2 Processing Mobility Headers
>>  says that _anybody_ processing a received Mobility Header whose 
>> Type is not understood should send a BErr.  That means that a HA 
>> should too (not only a CN); and regardless of whether the 
>> originator of that message is a MN registered to the HA or not 
>> registered.
>> 
>> Both HA and CN should be able to build BErr messages.  If the 
>> document doesn't say so then it should.
>> 
>> It is not enough to relegate this behaviour to a single statement 
>> in rfc "A CN can be a HA, or a HA can be a CN, or anybody should be
>>  send a BErr".  It should clearly say "A HA should be able to send
>>  BErr".
> 
> I agree. I think that HA should process the packet w/ Home Address 
> Option and the BE(status 1) like the first three paragraphs of 
> Section 9.3.1.

YEs, an easy way to accomplish this is to have 3 paragraphs.  Each
paragraph lists the messages an entity sends and the messages it
receives.  A sort of summary.  For example: HA sends BErr, BAck, MPD
Adv, etc and receives BU, MPD Sol, etc.

This kind of summary could be useful for someone planning on
implementing Mobile IPv6.  This summary avoids the reader the effort to
browse back and forth in the document during the essential planning phase.

Alex

---

From: "K.Kawaguchi" <[email-masked]>
Date: Tue, 16 Jan 2007 14:33:16 +0900

Hi,

Please let me announce the TAHI conformance tool because the tool was
referred in the this discussion.
(Though this might repeat my description.)

TAHI conformance test tool keeps the present test specification.
(We wish that the HA specifications be more clear when updating RFC in
 the future.)

The test specification interprets RFC3775 as follows now.

a) Whether HA transmits BRR or not.

   => HA doesn't send BRR.
      Not describing the BRR function in HA shows that HA doesn't
      tacitly have the BRR function. Because HA is passive compared
      with MN, and has Lifetime and Binding Refresh Advice mobility
      option of BA, it is thought that there is no necessity.

b) How should HA do, when HA receives the packet of Echo Request with
   Home Address destination option from MN where HA has the binding
   cache entry.

   => HA replies Echo Reply wtih type2 routing headr.
      When HA sends the packet to MN, the processing of HA is the same
      as CN (10.4.2 refer to 9.3.2 in RFC3775).
      In view of the situation, when HA receives the packet from MN,
      the processing of HA is the same as CN (so 10.4.x seems to have
      missed the reference to 9.3.1.).

c) How should HA do, when HA receives the packet of Echo Request with
   Home Address destination option from node where HA hasn't the binding
   cache entry.

   => HA replies Binding Error(status 1).
      The reason is the same as b).

Best regards
---
Kiyoaki KAWAGUCHI

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jan 2007 15:08:44 +0100

Kiyoaki, thanks for the response and action.

> (Though this might repeat my description.)

Yes, thanks for clarification.  On a tangent note, can I ask what's the 
relationship between TAHI conformance tool and IPv6 Gold Logo?  Does the 
clarification you made about the TAHI conformance tool equally apply to 
IPv6 Gold Logo?  Is this the intention?

>       option of BA, it is thought that there is no necessity.

Depending on the relationship with the IPv6 Gold Logo, should I deduce 
that a Gold Logo certified HA that does (a1) 'basic features' will not 
have to send BRR?

If HA does send BRR does it mean it implements (a2) 'advanced feature'? 
  Or does it mean it's a 'rankC' testing (non basic, non advanced 
features, a 'MAY' in RFC).

>       missed the reference to 9.3.1.).

Ok, I think this is agreed by several persons, myself included.

>       The reason is the same as b).

I agree, HA should send Binding Errors, even to nodes it does manage but 
for which it doesn't have a BC entry.

Thanks,

Alex

---

From: "K.Kawaguchi" <[email-masked]>
Date: Fri, 19 Jan 2007 11:43:17 +0900

Hi,

> IPv6 Gold Logo?  Is this the intention?

Yes. We have already offered the TAHI tool as a conformance test of
IPv6 Ready Phase-2(Gold) Logo.

The specification interpretation that I described is consistent with
present Logo conformance test specification. The TAHI tool follows the
Logo conformance test specification.

> features, a 'MAY' in RFC).

Now, there are no test item of BRR in the HA test specification.
However, BRR should not be sent in the HA conformance test. When the
message that HA is not to send is detected, it is judged a fail.

I think that BRR in HA is interpreted as a local additional function
now. It is necessary to disable BRR in Logo conformance test.

Best regards
---
Kiyoaki KAWAGUCHI

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 31 Jan 2007 14:24:00 -0800

Hello Kawaguchi-san,

Sorry for the late reply.

> a) Whether HA transmits BRR or not.

That is correct.

>       The reason is the same as b).

No. If you want to interpret RFC 3775 accurately, the HA
should send a binding error (status 1) only if the home
address in the home address option does not belong to the
home prefix served by the HA. If the HA is the home agent
for that mobile node, the packet should be dropped (no
binding error is sent).

Vijay

---

From: "K.Kawaguchi" <[email-masked]>
Date: Thu, 1 Feb 2007 12:19:28 +0900

Hi,

Thank you for your comment.

Excuse me, I do not understand your sentence enough. Please let me
confirm it in a more concrete example.

I try to enumerate some patterns, though it doesn't understand be
suitable for your intention.

- There are the home prefix 2001:DB8:1:1::/64 served by the HA.
- The HA has one binding cache entry for the MN-1.
- The MN-1 home address is 2001:DB8:1:1::1.
- The MN-1 primary care-of address is 2001:DB8:100:100::1.

How should the HA do, if the HA receives the following echo request with
the home address option.

1) The "well known" addresses in the echo request.

    Echo request with the home address option
      src: MN primary care-of address (2001:DB8:100:100::1)
      dst: HA address
      home address option, home address: MN home address (2001:DB8:1:1::1)

    It is echo reply with the type2 routing header in my understanding.
      src: HA address
      dst: MN primary care-of address (2001:DB8:100:100::1)
      type2 routing header, home address: MN home address (2001:DB8:1:1::1)

2) The unknown address in the source address field.

    Echo request with the home address option
      src: unknown address (2001:DB8:100:100::2)
      dst: HA address
      home address option, home address: MN home address (2001:DB8:1:1::1)

    It is binding error in my understanding.
      src: HA address
      dst: 2001:DB8:100:100::2
      BE header, status      : 1
                 home address: 2001:DB8:1:1::1

3) The unknown address in the home address field of the home address
   option. It is in home prefix.

    Echo request with the home address option
      src: MN primary Care-of Address (2001:DB8:100:100::1)
      dst: HA Address
      Home Address Option, home address: unknown address (2001:DB8:1:1::3)

    It is binding error in my understanding.
      src: HA address
      dst: 2001:DB8:100:100::1
      BE header, status      : 1
                 home address: 2001:DB8:1:1::3

4) The unknown address in the home address field of the home address
   option. It isn't in home prefix.

    Echo request with the home address option
      src: MN primary Care-of Address (2001:DB8:100:100::1)
      dst: HA Address
      Home Address Option, home address: unknown address (2001:DB8:4:4::4)

    It is binding error in my understanding.
      src: HA address
      dst: 2001:DB8:100:100::1
      BE header, status      : 1
                 home address: 2001:DB8:4:4::4

5) The unknown address in the source address field.
   The unknown address in the home address field of the home address
   option. It is in home prefix.

    Echo request with the home address option
      src: unknown address (2001:DB8:500:500::5)
      dst: HA Address
      Home Address Option, home address: unknown address (2001:DB8:1:1::5)

    It is binding error in my understanding.
      src: HA Address
      dst: 2001:DB8:500:500::5
      BE header, status      : 1
                 home address: 2001:DB8:1:1::5

6) The unknown address in the source address field.
   The unknown address in the home address field of the home address
   option. It isn't in home prefix.

    Echo request with the home address option
    src: unknown address (2001:DB8:600:600::6)
    dst: HA Address
    home address in Home Address Option: unknown address (2001:DB8:6:6::6)

    It is binding error in my understanding.
      src: HA Address
      dst: 2001:DB8:600:600::6
      BE header, status      : 1
                 home address: 2001:DB8:6:6::6

Best regards
---
Kiyoaki KAWAGUCHI