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

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Dec 2006 14:11:29 +0100

Hi mip6ers,

I'm trying to clarify the following ping scenario: MN sends an ICMP Echo
Request to its HA, as a non-tunnelled packet.  Src: CoA, Dst: HA@ and
DO: HoA.

Remark this is a non-tunnelled packet.

Should the HA simply send back ICMP echo replies to the CoA?  Or should
the HA be bothered by the HoA in DO and send back the echo reply _only_
if the corresponding binding cache entry (HoA-CoA) exists, and otherwise
send a Binding Error to MN?

I'm tempted to say that HA should ignore the HoA in DO and just reply
back to MN.  MN and HA should still act as simple hosts and ping each
other non-tunnelled.

This came up in some testing we do.

Thanks,

Alex

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

---

From: Francis Dupont <[email-masked]>
Date: Mon, 25 Dec 2006 09:33:54 +0100

In your previous mail you wrote:

   
=> in fact it is the standard way to send a direct packet from MN to HA
(as the HA is a common CN for direct traffic).

=> none of them: the HA ICMP engine should send replies to the MN HoA
and the MIPv6 code should add a type 2 RH through the registered CoA
(which can be the same of a different address).

=> if you want that you must avoid the DO, usually it is done by forcing
the source address to the CoA.

Merry Christmas!

[email-masked]

---

From: "Mondemu Sreenivasulu-A21119" <[email-masked]>
Date: Wed, 27 Dec 2006 22:18:55 +0800

Hi Alex,

As part of tahi self tests, when HA receives Echo request with HAO
(Src:COA, Dst: HA and HAO:Home address of MN), it has to send Echo Reply
with RT2 (Src:HA, Dst:COA and RT2: Home address of MN)if it has entry in
Binding cache for Home address of MN, else it has to binding error
message.

It is very clear from RFC whether it is a expected scenario.

Thanks,
Sreeni.
-----Original Message-----
From: Petrescu Alexandru-AAP021 
Sent: Friday, December 22, 2006 6:41 PM
To: [email-masked]
Subject: [Mip6] Non-tunnelled Echo Req MN to HA

Hi mip6ers,

Thanks,

Alex

---

From: "Mondemu Sreenivasulu-A21119" <[email-masked]>
Date: Thu, 28 Dec 2006 15:46:30 +0800

Sorry, The small correction. It is not very clear from RFC 3775 whether
it is a expected scenario.

Thanks & regards
Sreeni 

-----Original Message-----
From: Mondemu Sreenivasulu-A21119 
Sent: Wednesday, December 27, 2006 7:49 PM
To: Petrescu Alexandru-AAP021; [email-masked]
Subject: RE: [Mip6] Non-tunnelled Echo Req MN to HA

Hi Alex,

It is not very clear from RFC whether it is a expected scenario.

Thanks,
Sreeni.
-----Original Message-----
From: Petrescu Alexandru-AAP021
Sent: Friday, December 22, 2006 6:41 PM
To: [email-masked]
Subject: [Mip6] Non-tunnelled Echo Req MN to HA

Hi mip6ers,

Thanks,

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 28 Dec 2006 11:16:56 -0800

> 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.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 29 Dec 2006 13:10:14 +0100

Francis Dupont wrote:
>> I'm trying to clarify the following ping scenario: MN sends an ICMP
>>  Echo Request to its HA, as a non-tunnelled packet.  Src: CoA, Dst:
>>  HA@ and DO: HoA.
>> 
> => in fact it is the standard way to send a direct packet from MN to 
> HA (as the HA is a common CN for direct traffic).

Yes, it is the standard way to communicate between MN and HA.  I'm not
sure though what is meant by 'HA is a common CN' in usual discussion.
This is something we've discussed separately (eg does HA send a BRR, as
a CN would) and there was no conclusive decision.  This is something
needed very often in implementation.  For example let's say I embark in
implementing an HA.  Should I make it send BRRs or not.

This pinging HA question also reflects a need for clarification.

>> Should the HA simply send back ICMP echo replies to the CoA?  Or 
>> should the HA be bothered by the HoA in DO and send back the echo 
>> reply _only_ if the corresponding binding cache entry (HoA-CoA) 
>> exists, and otherwise send a Binding Error to MN?
> 

Ok.

>> I'm tempted to say that HA should ignore the HoA in DO and just
>> reply back to MN.  MN and HA should still act as simple hosts and
>> ping each other non-tunnelled.
> 
> => if you want that you must avoid the DO, usually it is done by 
> forcing the source address to the CoA.

Errr... I understand the principle: don't put DO in Echo Req and thus
the Echo Reply won't have an RH.  (the src address _is_ the CoA).  But
the ping program is not capable to optionally add DO or not.

> Merry Christmas!

Thanks !  Et Bonnes Fetes !

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 29 Dec 2006 13:21:37 +0100

Vijay Devarapalli 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.

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).

Alex

> 
> Vijay
> 
>> 
>> Thanks & regards Sreeni -----Original Message----- From: Mondemu 
>> Sreenivasulu-A21119 Sent: Wednesday, December 27, 2006 7:49 PM To:
>>  Petrescu Alexandru-AAP021; [email-masked] Subject: RE: [Mip6] 
>> Non-tunnelled Echo Req MN to HA
>> 
>> Hi Alex,
>> 
>> (Src:COA, Dst: HA and HAO:Home address of MN), it has to send Echo 
>> Reply with RT2 (Src:HA, Dst:COA and RT2: Home address of MN)if it 
>> has entry in Binding cache for Home address of MN, else it has to 
>> binding error message.
>> 
>> Thanks, Sreeni. -----Original Message----- From: Petrescu 
>> Alexandru-AAP021 Sent: Friday, December 22, 2006 6:41 PM To: 
>> [email-masked] Subject: [Mip6] Non-tunnelled Echo Req MN to HA
>> 
>> Hi mip6ers,
>> 
>> _______________________________________________ Mip6 mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
>> 
>> _______________________________________________ Mip6 mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
>> 
>> _______________________________________________ Mip6 mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
> 
>

---

From: "Vasudevan Pillai, Padmakumar A" <[email-masked]>
Date: Fri, 29 Dec 2006 18:54:51 +0530

Hi

See some clarifications. Look for <Pappan> inline.

Thanks

Pappan

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Friday, December 29, 2006 5:52 PM
To: Vijay Devarapalli
Cc: [email-masked]
Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA

 

<Pappan> Yes HA should send. HA received an echo request with DO; but HA
was not bound to MN.

This is a common case where an MIPv6 capable node (HA or MN or CN)
received a packet with Home address option, but the authenticity of the
this option is not provable by a supporting binding cache entry, because
the entry does not exists. This is an error condition and the node
should respond with a Binding error message.

<Pappan> in general CN is a common functionality. If you look at the
implementations, you will have CN alone or MN + CN or HA + CN
combinations. 

Alex

 

Mip6 mailing list

[email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 29 Dec 2006 15:05:11 +0100

Hi Pappan,

Vasudevan Pillai, Padmakumar A wrote:
> <Pappan> Yes HA should send. HA received an echo request with DO; but
>  HA was not bound to MN.

I agree it makes sense.  However, the RFC does never say so.  It says CN
should.

>  implementations, you will have CN alone or MN + CN or HA + CN 

What part of these implementations makes you say so?  Is a HA+CN
implementation called such?

I understand that a HA "is a kind of" CN, but what does that mean
exactly?  I understand HA would send a Binding Error, because it would
as a CN.  But will an HA act as a complete CN - in other words will HA
originate a CoT.  There are some things that only a pure CN will do that
a HA won't do.

Remark also that RO is the part of MIP6 that is least needed in some
deployments.  And thus an implementer of a HA may very well decide  to
not implement the CN part of a HA, which will leave that HA without BRR
and without BErr - because RFC says only CN implements BRR/BErr.  Those
two last messages are very needed outside the need for Route Optimization.

I suggest clarification in rfc3775 that states that HA does send Binding
Error, and Binding Refresh Request.

This would be in line with what TAHI tests do, inline with the original
authors' intent (IIRC) of HA having some of the CN's behaviour, and
still leave open the option of a HA implementer to not implement RO.

What do you think?  What do others think?

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 29 Dec 2006 10:49:12 -0800

> 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.

> 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.

There are many HA implementations that don't implement
the CN functionality or have the CN functionality turned
off.

Vijay